Something I keep coming back to: if an auditor asked your team to prove that the AI-generated code in your last release passed your risk policy what would you actually hand them?

Most teams I talk to would produce a PR link, maybe a Copilot usage dashboard, and a verbal description of their review process. No record of which model generated which function, no risk score at insertion time, no machine-verifiable proof that a human reviewed the AI context rather than just the diff.

We just shipped an indemnity certificate system in LineageLens. You define a policy (max risk score, allowed models, require human review, license clean), call an endpoint for a specific PR or release, and the system evaluates every provenance record tagged to that scope against your rules. Either it issues a signed Ed25519 certificate verifiable by any third party without workspace credentials or it returns a structured list of exactly what failed and why.

The certificate anchors to the provenance hash chain at the moment of issuance, so it's not just "we said it was reviewed." It's a cryptographic statement tied to the capture records that existed at the time.

Something that keeps coming up when I talk to teams about AI code governance: everyone focuses on capturing records, but almost nobody asks how confident they are in those records.

There are two very different things you can have.
Record A: a file-watcher noticed 47 lines appeared in auth.py and Cursor was probably running.
Record B:a proxy intercepted the Anthropic API call, matched it to the editor insertion via request UUID, measured 1.4 seconds between the API response and thecode appearing, and computed 0.81 trigram similarity between the model output and what landed in the file.

Both produce a row in your audit database. The second is dramatically more defensible but most governance tooling treats them identically.

In LineageLens, every record gets a confidence score from 0.0 to 1.0, broken into five independent evidence signals. Easy Mode captures (VS Code extension, no proxy) score around 0.27 honest about what you know. Power Mode captures (proxy running, full request interception) score up to 1.0. The score is not about whether the record is useful. It is about how much you can defend it when someone asks.

I started building LineageLens because I kept asking a question that nobody on my team could answer: if a CVE gets traced back to an AI-generated line in production next week, what evidence do we actually have?

Not "we use Copilot and review everything." Machine-readable evidence: which model generated which lines, with what prompt, at what confidence, and whether a human reviewed the AI context before it shipped.

For most teams, the answer is nothing. The Cloud Security Alliance put a number on it this month: 81% of organizations have no complete visibility into where AI-generated code lives in production. That gap grows larger every sprint.

LineageLens intercepts AI tool traffic at the proxy layer to capture provenance records at generation time -- the only moment when model, prompt, file path, and edit context all coexist. Then the blame engine maps those records onto current file contents:

Something I keep running into while building LineageLens: teams know they should review AI-generated code before it merges, but "reviewed" in practice means "someone clicked Approve." The diff could have been open for 3 seconds or 30 minutes. The record looks the same. I shipped a feature this week that tries to make this distinction real. Three behavioral signals time-per-line on the diff, comment count, lines reviewed get scored into a classification: `shallow`, `adequate`, or `deep`. Anything below 1 second per line gets hard-classified as `shallow` regardless of score, because no one is actually reading at that speed. The classification gets signed with Ed25519 and stored as an attestation. A CI gate endpoint then blocks merges when the review depth is below a configurable minimum. I have real doubts about parts of the formula. The comment signal is the weakest three "looks good" comments score the same as three substantive engagement comments. The 1-second-per-line floor is a judgment call that will occasionally misclassify a genuinely fast reviewer. And any behavioral proxy like this can be gamed if someone is motivated. But "approved" as the only review record for AI-generated auth code is not a governance posture it is an illusion of one. The question is whether a behavioral floor, even an imperfect one, is better than no floor at all. Curious if anyone here has built or worked with review quality measurement systems and what signals you found actually correlated with genuine engagement vs. nominal approval. Project: https://www.lineagelens.dev/

Monday is when this problem stops being theoretical.

A team uses three assistants, two editors, and one of those we ll figure out the provenance later workflows, and suddenly the question is not whether AI touched the code. The question is whether your audit trail can tell you what it actually saw.

That is the part I keep coming back to: a flat log is easy to build, but it is not honest enough for mixed-tool AI work. One assistant exposes prompt text, another only gives you metadata, another leaves you with an editor diff. If you flatten that into one record type, you have not built provenance. You have built confidence theater.

What I wanted LineageLens to do was simpler and stricter: make capture level explicit. If the system saw the whole prompt, say so. If it only saw metadata, say so. If it only saw the file diff, say so. If it saw nothing reliable, say that too.

People often think LineageLens is just about capturing AI-generated code, but the real value is what happens on
Day 2.

The dashboard turns those intercepted edits into a searchable audit trail. Instead of blindly digging through `git blame`, you can search past AI edits, trace the prompt-to-code workflow, and instantly answer why a specific model wrote a function that way.

Most AI provenance tools focus on parsing model output, but the failure mode I keep seeing is simpler: one layer says one thing, another layer says something slightly different, and users lose trust fast. In LineageLens, that meant fixing things like fresh-install auth redirects, Lite-mode 403 handling, workspace shape mismatches, and swallowed ingest warnings. At that point the product problem is no longer can we capture AI code? but can every surface tell the same story? Do you treat contract drift as a product bug, or only a backend bug?

Thanks for the massive support on the last update! I ve been heads-down rewriting the core engine of LineageLens, and I'm stoked to share the v1.1.5 release.

When building an audit trail for AI-generated code, the default approach is to try and regex markdown blocks out of the LLM s text response. It is incredibly brittle. For this release, we ripped that out entirely.

The LineageLens proxy now natively parses the underlying structured protocols:

• Anthropic s tool_use blocks (handling the streaming JSON assembly)

• OpenAI s apply_patch DSL (via the newer Responses API)

• Gemini s functionCall arrays

Most enterprise AI governance conversations focus on the wrong layer.

The hard part is not showing a dashboard with model usage. The hard part is building a control plane that still makes sense when someone joins, leaves, changes teams, or works in a different workspace. If the system cannot handle first boot safely, cannot revoke access cleanly, and cannot keep provenance inside your own infrastructure, then it is not really governing anything.

That is why the current LineageLens direction feels more like infrastructure than analytics. The backend now has a setup guard so the product stays locked until the first admin exists. It supports workspace-scoped invites, registration can be disabled, and token rotation means old sessions can be invalidated instead of lingering forever. On the capture side, even the free local extension preserves confidence and source, so evidence is not flattened into a raw diff.

I think that is the right shape for enterprise AI provenance. The important question is not what model wrote the code? It is who had access, what workspace was it in, and can we prove that the evidence still means something after access changes?

We built LineageLens because teams were wasting reviewer time guessing where unfamiliar code came from. Archival logs are useful for audits, but reviewers need provenance in the flow of review: a prompt, a model, and a confidence score attached to the diff. Recent product work focused on small, high-leverage UX and correlation improvements drag/drop captures, click-to-insert in vscode extension so provenance is readable and actionable in minutes, not days. I'm curious: in your org, how do reviewers triage unfamiliar code today reproduce prompts, ask the committer, or revert and re-implement? What one capability would make provenance useful for your reviewers tomorrow?