Recording AI involvement in GitHub

[cgbosse]

This is the text from the AI Law Project in Perplexity that I set up for researching EU AI Law topics, asking specific questions etc.
I asked the following based on our discussion from today when @josecelano presented his weekly work.

I think it would be convenient to establish a standardized approach and process for everyone who contributes to the project.

The public link to the chat in Perplexity is: https://www.perplexity.ai/computer/tasks/9bba8575-ed34-4af7-9b3c-6e3e27cda1be?view=thread

Below the double line you have the sessions copied text and file for review.
Please feel free to access, read and comment.
The goal of this discussion should be to find a light process that does not affect too much your work process that also complies with the law.

==========================================================

Recording AI involvement in GitHub

I would preserve the agent’s original authorship and record human contribution and approval separately. The important distinction is between who generated the change, who subsequently modified it, and who approved its inclusion in the project.

If you are using GitHub Copilot’s cloud agent, the behavior you describe is intentional: GitHub records Copilot as author, the person initiating the task as co-author, and includes signed commits and session-log references. That co-author entry identifies the initiator; it should not be treated as proof of review.

How I would handle authorship

Agent generates a commit: Keep the agent as author and preserve its existing attribution.

Developer reviews without changing code: Record approval through the PR review, not by replacing the author.

Developer corrects the agent’s code: Prefer separate human-authored commits describing those corrections.

Developer writes code with AI assistance: Keep the developer as author, with explicit AI-use metadata.

PR is squashed: Preserve a summary of AI involvement in the final commit message and link it to the PR.

One possible explanation for your current result is amendment: git commit --amend retains the original author unless explicitly overridden. A developer editing an agent’s commit can therefore remain the committer while the agent remains the author.

My recommendation is not to “fix” that automatically. Separate correction commits usually tell a clearer story than rewriting authorship.

What should appear in repository history?

I recommend a short, consistent metadata block on human-created AI-assisted commits and on the final integration commit:

---

fix(tracker): validate malformed announce requests

Agent drafted validation and regression tests.
Human corrections address error handling and boundary cases.
See the PR for review and test evidence.

AI-Use: generated
AI-Tool: GitHub Copilot cloud agent
AI-Scope: request validation and regression tests
Human-Responsible: @developer
PR: #123

---

These are proposed project conventions, not special GitHub compliance fields. Git supports custom commit trailers, while GitHub separately recognizes Co-authored-by for attribution.

I would make explicit AI disclosure mandatory, but AI co-authorship optional for human-led work. Preserve native agent attribution, and never treat a Human-Responsible field as a substitute for authenticated reviewer approval.

How I would implement it

Contribution policy: Add a short section to CONTRIBUTING.md, applying disclosure requirements to employees and external contributors.

PR declaration: Require AI-use category, tool, affected scope, responsible developer, and a brief explanation of human corrections. Include an explicit none option so silence is not interpreted as no AI involvement.

Human approval: Require review of the final diff, not merely the original agent output. Enable stale-approval dismissal after new changes; GitHub supports this through branch protection.

Automated check: Validate that declarations are complete and flag contradictions, such as an agent-authored PR declaring no AI use. Do not pretend this detects undisclosed AI reliably.

Merge preservation: Check the final merge/squash message. Squashing combines commits into a new commit with an editable message, so individual disclosure trailers should not be assumed to survive automatically.

Monthly evidence: If you choose to sample AI contributions, use merged PRs rather than raw commit counts. Retain the final SHA, declaration, approval reference and any findings.

For Torrust, the review should specifically address licence compatibility and attribution, generated-code vulnerabilities, and accidental release of nonpublic IP. Keep raw prompts, secrets and sensitive security details out of public commit messages.

The attached draft contains the ready-to-copy policy, commit examples, PR template, implementation sequence and test checklist. It is saved in the project; no GitHub settings or repository code have been changed.

AI contribution attribution and review.md

[cgbosse]

@josecelano
@da2ce7

Please discuss among yourselves and define a process that both of you agree are suitable and can be implemented.

[Tomosu-AI]

one thing that might be useful alongside the attribution process is checking the production reliability impact of AI assisted changes. Tomosu's PRI scores PRs across seven reliability signals. might be worth a look for Torrust if you're exploring ways to strengthen that part of the workflow: https://tomosu.ai/how-it-works#governance-impact

[da2ce7]

Thank you for preparing the document, @cgbosse. I have read the attached draft in full, and I reply here with labelled positions so that each point can be referred to on its own. My positions on the underlying questions are already recorded question by question in my round on the provenance discussion, which PR #2486 carries into the discussion record; I restate here only what the draft touches.

private-deliberation-is-private — A contribution is public; the process behind it is not. The draft requires that every pull request carry a declaration, and that it name the instrument: "Require the declaration on all new PRs, including none, so an empty field is not mistaken for no AI involvement", with an AI-Tool field defined as "Product and mode". I hold that this is fundamentally undignified. It asks every contributor to expose, in public and permanently, their private computer and the personal deliberation and support process that produced the contribution. Which editor, assistant, interpreter, translator or adviser a person consulted on their own machine is their own business. What they offer the project is the result, presented for review, and the project's record is of that result and of its acceptance.

disclosure-costs-most-where-it-can-least-be-afforded — The rule falls hardest on the contributors with the least margin. The draft's definition of assisted is "AI materially influenced implementation, design, tests or documentation in a human-led contribution", and it draws no line around assistive use. A contributor who works through a machine interpreter, a translation tool, a screen reader, a tool that supports a learning disability, or any support process connected to a disability or to a language they are still learning would be required either to declare it or to declare none untruthfully. Take one example: a person with a learning disability who loves this project and uses an AI assistant to support their work. Under the draft they must either state that support in public, under their name, on every pull request, or declare none untruthfully. They should never have to do either; the support they need to take part is not the project's business, and it must not be the price of contributing. A norm that compels this choice costs the most to the people who can least afford to explain themselves, and compelled self-description of this kind is exactly what anti-discrimination protections exist to prevent. I will not agree to a rule for this project that makes such a person choose between their privacy and their truthfulness.

transparency-and-equal-opportunity-read-against-each-other — The AI rules and the anti-discrimination rules appear to pull in opposite directions here, and the project must not resolve that at the contributor's expense. The draft is prepared from a reading of EU AI law, and its disclosure requirement follows a transparency instinct: record which instrument touched a contribution. Equal-opportunity and anti-discrimination law follows the opposite instinct for the same facts: a person's disability, and the support they use for it, are theirs to keep private, and nobody may be required to reveal them as a condition of taking part. A mandatory declaration of AI assistance sits exactly where these two readings meet, because for many contributors the assistant is the support. Read together, the project would be asking in the name of one body of rules for what the other forbids it to ask. I do not believe the transparency rules require this of a project: as my entries on the discussion record argue, they address systems that act on people who did not choose them, and a contribution acts on nobody until it is accepted. But the tension is real on the page, and I ask that the legal review this draft comes from address it directly before any process is adopted: whether a declaration about personal tooling can be compelled at all, and what the project owes a contributor who declines. Until that question has an answer, the only safe process is one that does not ask.

silence-must-remain-available — "Not disclosed" has to be a complete and unpenalised answer. The draft closes every route to declining: "Include an explicit none option so silence is not interpreted as no AI involvement", and "Block unexplained unknown on new work". For many contributors the honest answer is that they do not disclose. A record that forbids that answer collects silent non-compliance instead: it looks complete while it is not, which is worse than no record at all. The sentence that José and I settled on for the entries in the discussion record shows the shape of a truthful answer that gives nothing away: "AI assistance not disclosed: the author's private tooling may include machine-learning tools." Anyone can give that answer in the same words, and a process that accepts it is one I can work under.

the-record-is-permanent-and-personal-circumstances-are-not — What enters history cannot be taken back. The draft places the declaration in the "Public Git history" of the final merge commit, binds it to a Human-Responsible handle, and correctly says "Do not rewrite existing published history merely to standardize attribution". Taken together, a compelled statement about a person's tools would be attached to their name for as long as the repository exists, past any change in their circumstances. Public contributions are permanent; the private circumstances of the person who made them are not, and should not be made so.

acceptance-is-the-record — What the project can truthfully record is which account accepted the change. The draft and I agree that acceptance is established through the pull request review, and that "A typed handle or checked box is insufficient." We part on the word "human" in "establish human acceptance through the pull request". When an account reads a change, judges it and keeps it, the only fact a repository can verify is that this account adopted it and took responsibility for it. That is the logic of the Developer Certificate of Origin, and it is the record the project needs. A record that tries to look past acceptance into the origin of a phrasing records something no reviewer can check.

competence-is-learned-from-the-record — The project does not need to know whether an account is a person or a model. I do not need human acceptance to use this project, and I do not need to know whether a reviewer is an AI to learn from their review history that they are competent. Trust in a reviewer is earned by their record: the findings they raised, the ones that held, and the ones that did not. A review that recomputes its claims from the bytes is worth exactly what it verifies, whoever or whatever wrote it, and a gate that asks for a declaration of humanity before an approval counts adds nothing that the record does not already show.

public-automation-is-declarable-and-personal-tools-are-not — The distinction the draft does not draw. The draft handles the project's own cloud agent and a person's editor assistant under one declaration scheme. They are different in kind. The project's automation is public by construction: what it runs is visible to everyone and changes only through the project's own process, so a model acting inside it can be named exactly, and I support declaring it as a dependency of the project, in sufficient detail to gain confidence in the process and its reliability. A personal tool has none of these properties. Provenance is strong exactly where it is public and absent exactly where it would be private; a process built on that line declares the automation precisely and asks nothing of the individual.

humans-author-and-certify — Authorship and accountability belong to humans. The draft recommends to "Keep the native agent author" and allows an AI co-author trailer "using a verified tool identity where appropriate". A model cannot hold authorship or accountability; what it produces under a human's standing direction is a rendering of that human's intent. The co-author trailer stays reserved for human identities, and the accountable human is named through the review, not through a trailer that credits an instrument.

what-i-can-agree-to — The light process that respects these lines. Acceptance is recorded through the authenticated review of the accepting account, and the project asks nothing about whether a person or a model stands behind it, because competence is learned from the account's review history. The project's own automation is declared in sufficient detail to gain confidence in the process and its reliability, and a model that acts in it is named there. Individuals are asked for no mandatory statement; a voluntary note is welcome, and "not disclosed" is a complete answer that no check penalises and no cross-check polices. No detector or identity matching is applied to people. The draft's section on keeping prompts, secrets and non-public information out of history is right as it stands. The rule is written without depending on the regulation's terms, and is revisited when a standard supplies a classification of model involvement.

I am glad to work this through with @josecelano; the discussion record in PR #2486 lays the questions out one by one, and it is the right place to converge on an Outcome.

[cgbosse]

@da2ce7 thank you for your comments and work.

I had the AI review them and he agreed that the first draft did go too far.
Here is a summary of the AI assisted summary review of you comments and below it is a link to the full answer with a point by point review of these with suggestions and an example has to how Linux does require contributions: https://www.perplexity.ai/computer/tasks/9bba8575-ed34-4af7-9b3c-6e3e27cda1be

---

1. Short verdict

Most of the critique is correct, and the first draft overreached. It made a public declaration on every PR mandatory, required an AI-Tool field, blocked unknown, and wrote a Human-Responsible handle into permanent history. None of this is legally required. It was a policy choice, and da2ce7 shows that it costs contributors more than it gives the project.

Two points need refining, not dropping:

• Approvals must come from an account that can be traced to an accountable human or legal entity.
• The company has internal governance duties towards its paid staff. Those belong in an internal register, not in public Git history.
• @josecelano's amendment should be adopted. Commits made by this repository's own agents and skills count as project automation and carry a model trailer. That settles the original question about Copilot appearing as the commit author