TraceMap

Change review brief

Prepare the review conversation from static evidence.

A change review brief is a bounded static-evidence packet for a PR, release, or change-review conversation. It records what changed, visible static dependency surfaces, evidence backing the review question, partial or unknown coverage, and the owner for next verification.

Public claim level: concept. No public conclusion without evidence. The brief reduces meeting fog by keeping every statement attached to proof, limits, and ownership.

Audience

One packet can serve several review roles without changing the proof boundary.

EngineersUse the brief to see the changed area, nearby static surfaces, and the review question before reading source.
Code reviewersUse it to ask which rule-backed path, tier, file span, or limitation supports a review prompt.
Architects and managersUse it to keep scope, tradeoffs, and ownership visible without turning the packet into certainty.
Release reviewers and agentsUse it as handoff context for questions that still require tests, runtime owners, source review, release process, or human judgment.

Change Context

Start with the question before listing evidence.

review questionWhat specific change-review question is this brief preparing, and who asked for the review?
changed areaWhich public-safe branch, commit context, component name, contract, route family, package family, or file area frames the conversation?
review triggerWas the prompt a PR, planned release discussion, architecture concern, owner handoff, or agent-prepared review packet?
outside scopeWhich runtime, incident, deployment, ownership, or release-process questions must move to a different owner or route?

Evidence Packet

The packet carries provenance, support, and limits together.

Proof path

Name the public-safe path a reviewer can follow from summary to evidence. If the path is missing, keep the statement as a question.

Rule ID or rule family

Use a rule ID when it is public-safe and specific. Use a rule-family label only with the limitation that the exact rule is not available for this public brief.

Visible static dependency surfaces

List HTTP route references, HTTP client references, SQL-facing references, package references, or config references as visible review inputs, not behavior proof.

Evidence tier

Transcribe Tier1Semantic, Tier2Structural, Tier3SyntaxOrTextual, or Tier4Unknown without upgrading the tier in meeting notes.

Coverage label

Keep complete, partial, reduced, unavailable, future-only, or unknown coverage labels visible so the next question does not sound stronger than the packet.

Public-safe source context

Include file path and line span when public-safe, plus commit SHA and extractor version as provenance for the repository snapshot and extractor behavior.

Limitations

Carry parser gaps, semantic-load gaps, syntax-only evidence, framework gaps, and public-summary omissions beside the review prompt.

Non-claims

Record which conclusions the packet does not support so a summary cannot be upgraded by confidence, seniority, meeting repetition, manager pressure, or agent summary.

Review Questions

Turn static evidence into prompts, not conclusions.

Code reviewWhich changed file span, proof path, or rule family should a reviewer inspect first?
Test reviewWhich test owner should decide whether the visible surface needs deterministic test coverage?
Runtime reviewWhich service or runtime owner should answer questions that require logs, traces, metrics, dashboards, or deployment facts?
Release reviewWhich release reviewer should decide how this static packet fits the existing release process?
Architecture reviewWhich architect should review repeated dependency-surface questions or cross-component ownership boundaries?
Agent handoffWhat proof path, tier, limitation, and next owner must an agent include before handing the question to a human?

Stop Conditions

Stop when the packet cannot support the review wording.

missing proof pathDo not publish or repeat a conclusion when the proof path is absent.
private-only evidenceDo not convert private-only evidence into public copy until a reviewed public-safe summary exists.
unknown or reduced coverageKeep Tier4Unknown, unknown coverage, reduced coverage, unavailable coverage, and partial analysis visible as review limits.
unsupported runtime or release wordingStop wording that claims runtime behavior, production traffic, endpoint performance, outage cause, release safety, operational safety, release approval, or deployment state.
raw artifact exposureDo not expose raw facts, facts.ndjson, raw SQLite, index.sqlite, report.md, scan-manifest.json, logs/analyzer.log, analyzer logs, raw source snippets, raw SQL, config values, secrets, local paths, raw remotes, generated scan directories, private sample names, raw command output, hidden validation details, credentials, connection strings, table dumps, or database contents.
no named next ownerDo not close the handoff when no code owner, reviewer, test owner, runtime/service owner, release reviewer, architect, or agent handoff owner is named.

Next Owners

Every unresolved question needs a named receiver.

Code owner

Owns source-area interpretation and decides where source review should continue.

Reviewer

Owns the review prompt and checks that the summary still matches its cited evidence.

Test owner

Owns questions about deterministic tests or test gaps raised by visible static surfaces.

Runtime or service owner

Owns questions that need runtime systems, deployment facts, service context, or operational interpretation.

Release reviewer

Owns how the packet enters release review without treating static evidence as release outcome proof.

Architect

Owns recurring dependency-surface or ownership-boundary questions that outlive one PR.

Agent handoff owner

Owns the final proof path, limitation, and receiver list before an agent-prepared packet leaves the thread.

Limitations

Reduced evidence stays visible.

Partial analysisSemantic load failures, parser limits, framework gaps, or syntax-only evidence can reduce coverage.
Unknown proofTier4Unknown, unavailable proof, future-only proof, and unknown coverage are review inputs, not conclusions.
Public boundaryPrivate repository evidence needs private review before any public-safe summary is written.
Static boundaryStatic evidence can prepare a review conversation, but human reviewers, tests, runtime observability, source review, owner confirmation, release review, and human judgment remain responsible for their own decisions.

Non-Claims

This brief names what TraceMap is not claiming.

release boundaryA change review brief is not release approval and does not approve a release.
replacement boundaryThe brief does not replace tests, code review, source review, runtime observability, release review, owner confirmation, or human judgment.
runtime boundaryThe brief is not runtime proof, production safety proof, operational safety proof, production traffic proof, endpoint performance proof, outage cause proof, production proven evidence, operational assurance, or a production observability tool.
certainty boundaryThe brief does not say a system, endpoint, dependency, feature, or release is safe, unsafe, approved, blocked, validated for release, or completely covered.
analysis boundaryThe brief is not AI impact analysis, LLM analysis, prompt-based classification, embedding search, vector database analysis, or complete product coverage proof.