Git records who pressed merge, not who wrote the code, and in 2026 those are increasingly different entities. A new paper, F(AI)2R (arXiv:2607.25637), submitted 2026-07-28 by Florian Krebs, proposes closing that gap with a machine-readable provenance graph, gated by CI on every push, in which agents author claims and only humans may attest to them. For teams already running planner, coder, and reviewer agents, the consequence is direct: maintain a provenance ledger now, or lose auditability the first time an incident postmortem asks who actually wrote the failing block.
Why does git blame credit the merger instead of the model?
Git’s attribution model assumes one author per commit and treats authorship as a property of whoever ran git commit. When a coding agent drafts a function, a second agent refactors it, and a human resolves the merge conflict and pushes, every line lands under the human’s name. The commit graph flattens a multi-party production process into a single signature.
This was a tolerable fiction when agents were autocomplete. It stops being tolerable at current deployment scale. Claude Code v2.1.181, released 2026-06-17, ships a Rust port of Bun that its makers confirm is running “in production across millions of different devices.” Agent-written, agent-shipped tooling now sits underneath a large fraction of the developer population, and none of it carries per-block authorship records. The vendor side has noticed the accountability problem, but at a different layer: OpenAI documented its internal oversight of coding agents in March 2026, describing monitoring for misalignment in agent behavior. That is observability of what an agent does, not attribution of what an agent wrote. A postmortem that asks “which model produced this deserialization logic, and did anyone check it” gets no answer from either git or an agent-monitoring dashboard.
The practical failure mode shows up in two places. In code review, a reviewer reading a PR cannot distinguish the block a senior engineer wrote from the block an agent generated and the engineer skimmed; both carry the same author field, so review effort gets allocated blind. In incident response, blame and credit collapse into whoever pressed merge, which is precisely the person least likely to have authored the defect. Teams that have run a postmortem on agent-authored code will recognize the exercise: reconstructing authorship from Slack threads, session logs, and the committer’s memory. That reconstruction is forensic archaeology, and it gets worse every month the team ships without a ledger.
What does F(AI)2R actually propose?
F(AI)2R reframes provenance as “an executable skill that an AI agent operates itself,” per the paper’s abstract, rather than as documentation a human writes after the fact. The agent records its own activities, claims, and sources into a structured provenance graph as it works, and the graph is versioned alongside the artefact it describes.
The paper was written in the context of scholarly production, where the artefact is a paper and the claims are sentences. Its generalization is the part that matters for engineering teams: the model ships as “aiprov, a PROV-O extension covering any AI-in-the-loop artefact.” PROV-O is the W3C’s OWL ontology for provenance, built around entities, activities, and agents, with derivation and attribution relations between them. Extending it means the output is a machine-readable graph that existing provenance tooling can parse, query, and validate, rather than a prose appendix or a PR-template text field. Code is an artefact like any other under this model. A function body is an entity, an agent’s generation step is an activity, and the wasAttributedTo relation between them is the record git does not keep.
The design choice worth noting is that recording is the agent’s job, not the human’s. This inverts the usual provenance workflow, where a human annotates a document with metadata after finishing it and inevitably annotates less as deadline pressure rises. An agent that emits provenance records as a side effect of each action produces the ledger at zero marginal effort per claim. The cost moves from authoring time to verification time, which is where the paper’s second mechanism, the human attestation layer, comes in.
What are the two invariants that make the ledger verifiable?
The provenance graph is governed by two rules, stated in the paper: “no parentless claim, and verification rungs that only humans may grant.” Every recorded claim must trace to a source or a prior activity, and every step up the trust ladder must be executed by a human. Machines can author. Only humans can attest.
The first invariant blocks the most common provenance failure: an assertion floating free of any derivation. In a scholarly graph, that is a claim with no citation and no generating activity. In a code graph, the equivalent is a block with no record of which activity produced it, which is exactly what git gives you today for every agent-authored line. Enforcing parentage at the graph level turns “where did this come from” from an interview question into a query.
The second invariant is the load-bearing one. A provenance ledger where agents can verify their own output is a ledger that records the fox’s attendance at the henhouse and nothing else. By restricting verification rungs to humans, the model makes the trust structure explicit: the graph distinguishes “agent X generated this” from “a human confirmed this,” and those are different edges with different semantics. A CI system can then ask the only question that matters for a merge decision: has every claim in this changeset been carried up to a human-granted rung, or is some of it still sitting at agent-generated status?
The asymmetry also maps cleanly onto how engineering teams already think. Nobody proposes letting an agent approve its own PR. F(AI)2R makes that intuition structural rather than procedural: instead of a team norm that says “a human must review,” the graph itself cannot represent a valid verification without a human agent node. Norms erode under deadline pressure. Schema constraints do not.
How does provenance become a CI gate?
F(AI)2R’s setup asks the human operator for their ORCID ID and resolves their identity against the public registry before any provenance is recorded, then “scaffolds continuous integration that gates every push on graph conformance and publishes the current build,” according to the paper. Provenance stops being a documentation step and becomes a build requirement: a push whose graph violates an invariant fails like a failing test.
Two details carry the weight here. The first is identity resolution. ORCID is a scholarly registry, but the mechanism is the point: the human attestation rungs only mean something if “human” is a resolvable, persistent identity rather than a string in a config file. An engineering adaptation would substitute whatever the organization already trusts, an SSO identity, a GPG key, a hardware-backed credential. The pattern is the same either way. The graph binds attestations to identities that outlive a session, so an audit six months later can establish who attested, not just that someone did.
The second is the gate itself. Most current attempts at AI attribution in engineering live in PR templates: a checkbox reading “this PR contains AI-generated code,” filled in by the person opening the PR, at whatever granularity they feel like, with no validation. That is a self-report field, and self-report fields decay into cargo cult within a quarter. A CI gate inverts the incentive. The build fails unless the graph conforms, so the ledger stays current for the same reason tests stay passing: the alternative is not shipping.
This is also where the cost lands, and the paper is honest about the shape of it if not the number. Graph conformance checking on every push adds CI overhead proportional to graph size and validation complexity, and the paper reports no measurement of that overhead on a high-throughput repository. A monorepo with hundreds of agent-assisted commits per day would need the conformance check to run in seconds and the ledger format to stay append-friendly, or the gate becomes the bottleneck engineers route around. Routing around a provenance gate is worse than not having one, because it produces a ledger that looks complete and is not.
How does this hold up with planner, coder, and reviewer agents?
A single-agent workflow produces a linear graph: one agent, one chain of activities, one human verifier. The multi-agent workflows teams actually run, a planner decomposing a ticket, a coder implementing each subtask, a reviewer agent checking the diff, break that linearity. Now the ledger must record that the coder’s output derives from the planner’s decomposition, that the reviewer agent’s comments are agent-authored claims (not verification, since verification is human-only), and that the human’s final attestation sits above all three. The provenance graph becomes a coordination artifact, not just an audit trail.
The Code as Agent Harness survey (arXiv:2605.18747), submitted 2026-05-18, catalogs the open problems in multi-agent coding systems and names two that are exactly this: “consistent shared state across multiple agents” and “human oversight for safety-critical actions.” A shared provenance ledger is one concrete instantiation of the shared-state problem. If the planner and coder run in separate harnesses with separate session state, the derivation edge between the plan and the code exists nowhere except in the team’s memory of how the workflow was wired. The survey treats shared state as unsolved infrastructure, which is a fair reading of where multi-agent tooling sits in mid-2026.
There is also a subtle benefit to forcing the graph structure onto a multi-agent pipeline: it exposes phantom verification. If the team’s process is “the reviewer agent checked it,” the graph makes visible that no human-granted rung exists, because the reviewer agent cannot grant one. Teams that believe they have human oversight sometimes discover, on drawing the graph, that the human’s role is pressing merge on an agent-reviewed diff. The ledger does not fix that. It does make it undeniable.
What are the real decision axes for a provenance ledger?
The brief decision comes down to five axes, and the paper’s choices are not the only defensible ones. The table below maps each axis against the options a team would actually weigh.
| Decision axis | Options | Trade-off |
|---|---|---|
| Attribution granularity | Commit-level vs block/claim-level | Commit-level is cheap and nearly useless for postmortems; claim-level gives real auditability but multiplies graph size and CI cost |
| Audit format | Human-readable log vs machine-readable PROV-O graph | A text log is greppable but not validatable; a PROV-O extension like aiprov is queryable and gate-able but demands tooling most teams lack |
| Verification authority | Any committer vs human-only rungs | Letting agents verify agents collapses the trust model; human-only rungs preserve it but bound throughput by reviewer attention |
| CI integration | PR-template field vs push gate | Template fields decay into unchecked checkboxes; a push gate enforces the ledger but adds per-push overhead and a new failure mode to route around |
| Multi-agent coordination | Per-agent session logs vs shared provenance state | Session logs lose derivation edges between agents; shared state preserves them but is exactly the infrastructure the agent-harness survey calls unsolved |
The pattern across the table: every row is a choice between a cheap artifact that will not survive an audit and an expensive one that might. F(AI)2R’s contribution is picking the right side of each row and wiring the choices together, claim-level granularity, a PROV-O extension, human-only rungs, and a push gate, so the invariants reinforce each other. A team could adopt the ledger without the gate, or the graph without human-only rungs, and each partial adoption recovers some value. But the two invariants are the parts that make the rest auditable, and they are the parts a partial adoption is most likely to drop.
What does the tooling evidence say about adoption odds?
The strongest reason for skepticism is not technical. It is the adoption record of accountability tooling generally. The AI Accountability Infrastructure study (arXiv:2402.17861), published at CHI ‘25 from 35 practitioner interviews and a survey of 435 tools, concludes that “the available resources do not currently support the full scope of AI audit practitioners’ needs.” Four hundred thirty-five tools, and the practitioners still report a gap. Provenance ledgers land in exactly the tooling category that study describes: well-specified, academically sound, and chronically under-adopted because the cost is immediate and the payoff is deferred to an incident that may never come.
The second reason for skepticism is the paper’s own evidence base. F(AI)2R is self-referential by design: “Every activity, claim, and source in its production is recorded in the repository’s provenance graph,” the paper states, making the paper its own sole case study. That is a legitimate proof of concept and an honest framing, but it means the method has never run against a high-throughput multi-agent coding workflow. A scholarly paper has one artefact, a handful of claims per paragraph, and a publication cadence measured in months. A production repository has thousands of claims per day across parallel agent sessions, and the conformance gate sits in the hot path of every push. Nothing in the current deployment demonstrates the model survives that.
The counter-consideration is that the gate model sidesteps the usual adoption failure. Most accountability tooling fails because it depends on voluntary, after-the-fact compliance. A CI gate removes the voluntariness: the ledger is maintained because unmaintained ledgers fail builds, the same dynamic that keeps test suites honest in organizations that would never maintain them on discipline alone. The adoption question then shifts from “will engineers keep records” to “will organizations accept the CI cost,” which is a budget conversation rather than a culture conversation. Budget conversations get resolved.
Should your team build a provenance ledger now?
Teams running multiple coding agents should treat provenance as a CI gate rather than a PR-template checkbox: record each agent’s contribution and the human verification rung in a machine-readable graph, and fail pushes that violate the no-parentless-claim invariant. The specific implementation can diverge from the paper. ORCID can become SSO identity, the scholarly graph can become a per-repo ledger, the PROV-O extension can be adopted wholesale or mined for its two invariants and reimplemented in a simpler format. What cannot be dropped without losing the point is the pair of rules: every claim traces to a source, and only humans attest.
The strongest limitation bears repeating before anyone files the ticket. F(AI)2R’s only deployment is its own production. There is no third-party coding-agent workflow running aiprov, no published measurement of graph-conformance overhead on a busy repository, and no evidence yet that the human-attestation bottleneck stays tolerable at industrial commit rates. The audit-tooling evidence cuts the same direction: the gap between accountability tooling as specified and accountability tooling as adopted is the documented norm, per the CHI ‘25 study. A team that adopts the ledger now is doing early-adopter work, and should budget for it as such.
The alternative is the status quo, and the status quo has a price that is easy to miss because it is paid in a lump sum, at the worst moment. Git will keep crediting the merger. Agent-authored code will keep shipping at the scale of millions of devices, as the Claude Code toolchain already demonstrates. And the first postmortem that needs to know which model wrote the failing block and which human checked it will be answered from memory and chat logs, or not answered at all. Provenance is a first-class CI question now. The only remaining choice is whether a team answers it before the incident or during it.
Frequently Asked Questions
Can a team adopt the two invariants without the full PROV-O graph?
Yes, but the team loses the machine-readable validation that makes the CI gate possible. A JSON or YAML ledger can enforce the no-parentless-claim rule, yet it cannot be queried with PROV-O SPARQL endpoints or validated by existing ontology tooling. The trade-off is a ledger that is easier to build but harder to audit programmatically.
How does this differ from OpenAI’s internal agent monitoring?
OpenAI’s approach, documented in March 2026, focuses on runtime behavior and misalignment detection, which is an observability layer. F(AI)2R targets authorship attribution, which is an accountability layer. Monitoring tells you an agent acted unexpectedly; provenance tells you which agent generated a specific code block and who verified it. They solve different postmortem questions.
What is the cost floor for graph conformance checking?
The paper reports no measurement of overhead, but PROV-O validation typically requires loading the full graph into a reasoner, which scales poorly with high-frequency commits. A team processing hundreds of agent-assisted pushes daily would need to benchmark their specific graph size against CI latency budgets. If validation takes more than a few seconds, engineers will likely bypass the gate.
Does the human-only verification rule apply to reviewer agents?
Correct. Reviewer agents can generate claims and comments, but they cannot grant verification rungs. The graph explicitly marks agent reviews as unverified activities. This prevents a workflow where an agent reviews another agent’s output and the system treats it as human-approved. The human must still perform the final attestation.
