| name | decision-trace |
| description | WHEN checking what a meeting or transcript decided and whether specs, issues, PRs, and code carry it forward; NOT for summaries, glossaries, or implementation; preserves uncertainty across an evidence chain and reports current implementation status. |
Decision Trace
Follow the evidence chain from what people said to what the product does. Classify only explicit resolution as a decision. Keep the trace read-only; hand requested changes to an implementation workflow afterward.
1. Frame the claim
Rewrite the claim as a testable statement without strengthening it. Record the source scope, relevant repositories, and the branch, commit, or date that defines “current.” Use the available primary source regardless of provider.
Complete when: the claim, source scope, and current-code reference are explicit, with unavailable inputs recorded as gaps.
2. Establish the source record
Read enough of the primary conversation or decision record to capture qualification, objections, later resolution, and superseding statements. Quote only decisive words; attach speaker, date, and a precise locator. Label paraphrase and inference.
Classify each claim:
| Classification | Required evidence |
|---|
decision | An explicit selection, commitment, or resolution settled for a stated scope |
proposal | A suggestion, option, question, or intent without resolution |
disagreement | Incompatible positions remain unresolved |
unknown | Source, context, attribution, authority, or resolution is insufficient |
Prefer a later explicit resolution while preserving the chronology. Rationale supports a classification but does not prove a decision; silence and missing records remain unknown.
Complete when: every material supporting and contradictory excerpt is cited, and each claim has one classification with a stated confidence and evidence gap.
3. Build the chain
Follow the chain as far as evidence permits:
source statement → decision record/spec → issue → PR/commit → current code/test
Read every discovered artifact and cite the exact field, section, diff, commit, path, or line that connects it. Mark each link:
explicit — one artifact directly names or implements the otherinferred — scope and behavior align without a direct linkmissing — the expected handoff cannot be found
Artifact state is not behavioral proof: an approved spec, closed issue, or merged PR does not establish current behavior.
Complete when: each discovered artifact is placed in the chain and every transition is evidenced or marked inferred/missing.
4. Verify current implementation
Trace the current production path, callers, sibling paths, tests, configuration, and feature gates. Compare observable behavior with the classified claim, then run the smallest decisive checks available.
Assign one status per expected behavior:
| Status | Meaning |
|---|
implemented | Current code covers the behavior end to end and evidence passes |
partial | Some required paths or conditions are absent |
not implemented | Current code lacks the behavior |
diverged | Current code behaves differently |
unverified | Available access or evidence cannot decide behavior |
Complete when: every behavior implied by the claim maps to current code and verification evidence, or to a named gap.
5. Report the trace
Lead with the verdict, confidence, code reference, and date. Then provide:
- Source record: claim, classification, exact evidence, locator, and counterevidence.
- Artifact chain: each artifact and the evidence quality of every link.
- Implementation matrix: expected behavior, current code/test evidence, and status.
- Caveats and next work: missing sources, inferred links, unresolved disagreement, stale branches, absent tests, and the smallest action that would close each gap.
Keep fact, quotation, paraphrase, and inference distinct. End with the smallest evidence-backed next action.
