# From "Who Wrote This?" to "Provenance, Actioned": Making AI-origin code obvious during review > Source: > Published: 2026-05-29 07:21:22+00:00 TL;DR: The most useful provenance is actionable provenance. Instead of storing prompts like a dusty audit log, surface them where decision-makers work: the code review. Recent UX and correlation work in LineageLens — sidebar captures, drag/drop, click-to-insert, and a confidence engine — demonstrate how provenance can shorten review cycles and reduce reverts. The problem (why it matters) By 2026, AI is a first-class development tool. Good suggestions become accepted edits, then commits. When reviewers see unfamiliar code they ask the obvious questions: who wrote this, why was it accepted, and was it audited? Git blame shows an author, but not the conversational context that generated the code. That missing context causes three predictable costs: Time to reproduce: reviewers re-run prompts or attempt to reproduce edits. Conservative reverts: unknown edits get reverted, losing useful fixes. Risk hiding: sensitive changes slip through without proper checks. What "actionable provenance" looks like Actionable provenance answers reviewer questions immediately: Who/what produced this block (adapter + model) The original prompt text Confidence that the prompt maps to the inserted code Quick actions: insert into the editor, copy prompt to PR comment, or open the capturing session Minimal latency, clear UI, and one-click actions are the difference between “archival” and “actionable”. Recent product signals that make it practical (evidence from the repo) Drag-and-drop + click-to-insert (sidebar improvements): let reviewers place the original generated block into a temporary editor buffer or paste the prompt into the PR comment box. Confidence engine and dynamic routing: correlation scores and better adapter matching reduce false positives so reviewers can rely on the provenance instead of treating it as noise. UX fixes (trash/clear buttons, reorder, inline hover actions): small changes that keep the capture panel usable during real reviews. See the architecture summary in the repo: architecture.md:1 and the product README (README.md:1). Concrete workflow: a reviewer’s day with actionable provenance PR opens. Reviewer scans diffs. A capture badge is shown next to changed hunks indicating "Provenance: available — confidence 88%". Click: the capture sidebar opens to the exact prompt, model, and surrounding context snapshot. Action buttons: "Insert at cursor" — drop the generated block into a temp editor to run tests locally. "Copy prompt" — paste into a PR comment template to ask follow-ups. "Annotate PR" — append an auto-formatted provenance note (prompt, model, confidence). Outcome: reviewer spends <5 minutes to triage instead of 30–120. UX trade-offs and governance constraints Confidence thresholds: too low → noisy provenance, too high → missed attributions. Tune by starting conservative (show medium/high only) and lower threshold based on false-negative feedback. Privacy and storage: prompts can be sensitive. Default to workspace-local storage and make PR annotation an explicit reviewer action. Reviewer training: a short guideline (one paragraph) in your PR template — "If provenance shows 'high confidence', prefer triage over revert" — makes a measurable difference. Quick checklist to evaluate your team's readiness Are prompts stored in your control plane or vendor logs? If not, you may lack necessary evidence. Can you surface provenance inline in PRs or via your editor? If not, archival logs won't help reviewers. Do you have a workflow for annotating PRs with provenance? If not, create a two-line PR template snippet now.