COSMIC's AI Contribution Rule: Sell an Accepted Handoff, Not Generated Code

COSMIC's current pull-request template excludes LLM-generated code, comments, and descriptions. It also asks contributors to understand their changes, respond to review, test the contribution, and certify its origin. The rule is receiving fresh attention in early October; this article verifies the current repository template, not a newly established effective date or a ban across every System76 project.

For a founder buying an AI-built app, the immediate lesson is practical: producing working files and delivering work that its intended recipient can accept are different promises. A contractor might generate a useful integration quickly, yet be unable to contribute its fix upstream under that project's rules. Your launch then inherits a maintenance obligation that was absent from the demo.

This matters to nontechnical founders, app-building services, and small teams whose products depend on third-party repositories or customer handoffs. It is not an argument against AI-assisted development. It is a reason to define the destination before selling completion. The deliverable below is a reusable acceptance brief: who receives each artifact, what rules apply, what provenance can honestly be stated, and who maintains the work if that recipient declines it.

The central judgment is that an AI builder should promise a bounded, supported handoff. It should not promise upstream acceptance merely because tests pass. Most of the workflow below is a proposed product practice, not a measured result from COSMIC or a claim that we tested a submission there.

1. The receiving community sets a different kind of requirement

A pull request, or PR, proposes that another repository incorporate changes. That is distinct from keeping code in your own project. A contribution rule describes what that recipient will consider; a software license describes permissions and conditions for use and distribution. They can affect the same work without being interchangeable.

COSMIC's template is unusually clear about generated content. Editing the description by hand would not make generated code satisfy the stated requirement. Nor would a passing test or a human reviewer remove its production history. The proper decision is to stop that submission, clarify genuinely ambiguous cases through the project's permitted process, or choose another lawful and operationally viable delivery route. Do not treat paraphrasing as a provenance repair.

Other destinations differ. LLVM's policy permits tool assistance with human review and accountability, expects transparency for substantial generated content, and excludes autonomous publication without human approval. It also restricts AI use on issues intended for newcomer learning. Those are LLVM's conditions, not an exception to COSMIC's conditions.

For a founder, the useful question is therefore specific: where must this change end up for the product plan to work? If the answer is a customer's controlled repository, its rules matter. If the answer is upstream, upstream rules matter. If the answer is a privately maintained patch, your own maintenance capacity matters.

A product demo usually hides these distinctions. It shows an integration functioning in a temporary environment, not the recipient's agreement to own it. Ask the supplier to identify that missing agreement before calling the work finished. The destination is a dependency of the delivery promise, even when it is not a dependency in the application's package list.

2. Separate application delivery from upstream acceptance

Imagine a builder offering three outcomes: an app deployed in your account, a modified dependency maintained by your team, and an upstream contribution that eliminates the modification. Those outcomes have different owners and different failure conditions. Bundling them into a single “integration complete” checkbox obscures the remaining work.

GitHub's contribution guide describes the fork-and-PR process as proposing changes to another project. The mechanics give you a way to ask; they do not establish a right to merge. That distinction belongs in a customer-facing scope statement.

Use three separate acceptance events. First, the app operates in the agreed environment. Second, the customer receives the source, deployment access, and enough explanation to maintain the agreed behavior. Third, an external project accepts the proposed change, if that was part of the plan. A successful first event cannot silently stand in for the third.

If upstream acceptance is optional, say what happens while it is pending and after refusal. If it is essential, treat refusal as a blocked dependency, rather than reclassifying the work as complete. Do not promise a maintainer's response time, review outcome, or future release date on that maintainer's behalf.

A useful supplier statement is: “We can deliver the app with this temporary patch. Upstream inclusion is unconfirmed. Until replacement or acceptance, our named owner will maintain it within the agreed support scope.” That statement is narrower than a confident demo, but it lets a founder compare real alternatives.

It also improves pricing discussions. A cheaper build with an indefinite unsupported patch can be a worse purchase than a smaller feature that uses an unmodified dependency. The relevant tradeoff is the whole support obligation, not which route generated more code.

3. Treat provenance as a record, not a detector score

Provenance means the recorded origin and handling of an artifact. For this task, that includes whether a person wrote it, a tool generated it, someone adapted existing work, and what subsequent review actually occurred. A claim that text “looks human” does not answer those questions.

The Developer Certificate of Origin concerns the contributor's basis for submitting work under the indicated license and the public record of that contribution. It is not an AI quality score or a promise that every receiving community allows every generation method. Keep certification, destination rules, and functional review as separate questions.

The Linux kernel's coding-assistant guidance supplies another concrete example: it requires human responsibility and an assistance acknowledgment for relevant contributions. A receiving project may ask for that information even when generated output has been substantially edited. Follow the applicable project's wording rather than inventing a universal label.

For purchased work, ask the supplier to keep a lightweight origin record while building. A later reconstruction from memory can miss an AI-written comment, imported snippet, or generated explanation. The record need not preserve every private prompt. It should identify the affected artifacts, relevant source material, assistance used, review owner, and uncertainties that influence acceptance.

When the supplier cannot establish origin, write “unknown.” Do not turn an unknown into a clean declaration because delivery is urgent. Restrict the destination or replace the uncertain artifact through an appropriate process. Where rights or contract terms are material and unresolved, obtain the relevant specialist's decision before making a certification.

This is also a product design issue for builders. An export screen that invites customers to certify unverified origin creates confusion. Present the actual record and require an accountable person to assess the destination-specific statement. A generation tool cannot manufacture the historical facts needed to make that statement true.

4. An accountable human needs capacity, not a ceremonial checkbox

Human review is useful only when someone can explain the change, investigate an objection, and support the result. A founder does not need to become a compiler engineer to recognize when that capability is missing. Ask the delivery owner to explain a concrete failure and show the affected behavior.

For a login feature, ask what happens after session expiry. For an import workflow, ask how a partial failure appears to the user. For a modified dependency, ask what happens when the next update conflicts with the patch. These questions examine ownership of consequences rather than familiarity with technical vocabulary.

GitHub's responsible-use documentation for agentic features describes limitations including incomplete or inaccurate review feedback. That is a useful boundary for purchasing decisions: an AI review can help identify concerns, but its silence does not supply an accountable maintainer or prove readiness.

Define an owner for the artifact and a backup for absence. Record what each can do: reproduce the reported problem, identify the deployed version, explain the change, revise it, and restore the previous working state. If the supplier's only response to questions is to ask the same generator again, the support commitment remains uncertain.

For a small team, that may mean buying a few hours of relevant engineering review before purchase approval. It may also mean reducing scope to a component someone can understand. A small, explainable adaptation with an available owner is easier to sustain than an impressive unfamiliar subsystem.

Do not impose a performative rule that everyone must understand every line. Match expertise to the consequences and assign the technical portion honestly. The founder owns the purchase and release decision; the qualified reviewer owns the technical judgment within a stated scope. Both need the right to decline a handoff whose remaining obligations exceed their capacity.

5. Price the review and maintenance work left after generation

Cheap generation does not make review free. A contribution can arrive quickly while creating more work for the recipient than it removes. GitHub's Open Source Guide encourages understanding the project, communicating appropriately, and making contributions useful to its community. For an app buyer, those principles translate into a supplier obligation to reduce the next person's work.

Use a prospective cost worksheet rather than invented savings. Record build effort, qualified review, changes requested by the recipient, deployment verification, expected patch upkeep, and replacement work if acceptance fails. Put unknowns in a separate column. An estimate is not an observed cost, and upstream response effort cannot be scheduled unilaterally.

The following comparison is a decision aid, not a benchmark:

A privately maintained route is not automatically wrong. It can be the right temporary choice if the team accepts its ownership and has the right to use and distribute the resulting work. It becomes a bad promise when the supplier sells it as maintenance-free.

Track actual effort after delivery: review time, clarification rounds, update work, and unresolved questions. A low initial quote should not win by excluding those items from the comparison. Conversely, do not burden a trivial configuration change with the same process as an altered security-sensitive dependency. Scale the worksheet to the work that another person must actually accept.

6. A concrete scenario: the useful demo with the wrong destination

Consider a hypothetical service called HarborDesk. A nontechnical founder is buying a desktop companion for a customer-support workflow. A supplier's demo uses a generated patch to a COSMIC component to support a desired behavior. This is an illustrative purchasing scenario, not a documented COSMIC integration or a tested product.

The supplier initially says the patch will be sent upstream after launch, so the customer will avoid maintaining it. The founder asks for the receiving repository and its current contribution requirements. Once the template is checked, the proposed upstream route cannot honestly satisfy the no-generated-content declaration.

At that point, testing the demo again will answer the wrong question. It might confirm the feature works while leaving the delivery route blocked. The founder needs alternatives with explicit ownership, not a stronger claim that the code is good.

One alternative is to use an existing supported interface and accept a narrower experience. Another is to keep a lawful private adaptation with a named maintainer and a replacement milestone. A third is to commission a genuinely appropriate independent implementation, with qualified review of its origins and obligations. Merely rewriting the generated patch or its description does not establish eligibility; if a rule's application is unclear, seek clarification without misrepresenting how the work was produced.

The decision turns on customer need. If the desktop behavior is essential to a signed pilot, a supported temporary adaptation might deserve a bounded trial. If it is a visual enhancement, reducing scope may be wiser. The founder should compare consequences for users and ongoing support, not the emotional cost of discarding a polished demo.

HarborDesk's acceptance record should then say which route was chosen, who maintains it, what update would require another review, and what was never promised. That record protects the purchasing decision from gradually drifting back to the original assumption that upstream inclusion will happen automatically.

7. Use a destination-specific acceptance brief

The reusable artifact is a short brief completed for each meaningful handoff. It is a proposed operating template, not a COSMIC requirement. Keep it with the delivered source and support agreement, so the next person can distinguish accepted obligations from hopes.

Do not use this table as a checklist where every row must become green. “Pending upstream review; private maintenance accepted for this pilot” can be an honest limited outcome. “Unknown origin; certify as human-written” cannot.

Before handing over, have the recipient read the brief and explain the remaining obligations in their own words. This is a comprehension check, not a waiver. If the customer believes the supplier will maintain the patch while the supplier believes the customer will, resolve that mismatch before acceptance.

Store a snapshot or revision of important rules when practical. A floating URL alone may later describe a different policy. Recheck at submission or renewal; the record establishes what was reviewed, not permanent permission. For paid customer work, do not copy an open-source project's rule into the contract automatically. Use the customer's actual agreed requirements.

8. Make the product's states match the evidence

An AI app builder can help customers by showing distinct states: generated, reviewed for a defined scope, delivered to the customer, submitted externally, accepted externally, and supported in production. These states should reflect observable events rather than confidence language from the model.

“Submitted” needs an actual submission record. “Accepted” needs the recipient's decision. “Supported” needs an owner and an agreed scope. “Reviewed” needs the reviewed version and what the reviewer checked. When one of those is missing, show the narrower state instead of replacing it with “done.”

For repository-based delivery, GitHub's protected-branch documentation describes required reviews, status checks, and ways to dismiss stale approvals after changes. Those controls can help preserve a technical review boundary. They do not inspect whether an origin declaration is truthful or override a destination's contribution policy.

The practical design is to join the controls with the brief. After a material revision, update the artifact record and identify which acceptance evidence must be renewed. A changed comment could matter to a generated-content restriction even if it has no runtime effect. A changed dependency could matter to support even if the visible feature is unchanged.

Avoid asking founders to decipher internal agent traces. Show the affected promise: “The patch changed after review; technical acceptance is pending again,” or “External inclusion is unconfirmed; this release depends on our temporary maintenance plan.” Give a concrete next action and its owner.

A useful export also includes the source and instructions necessary to leave the builder. If the customer can only request another regeneration, the handoff may still depend on the supplier's service. Make that dependence explicit in the purchase scope rather than presenting an archive of files as full operational independence.

9. Check the failure modes before promising delivery

Run a short tabletop exercise before selling an acceptance-sensitive feature. No submission to a real external project is needed. The goal is to test your team's decisions when evidence or destination conditions change.

First, suppose the code passes but the recipient prohibits generated descriptions as well as code. Can the owner identify the affected artifacts and stop the prohibited handoff? Second, suppose a different project permits assistance with disclosure. Does the team retain accurate origins, or invent a label at the end?

Third, suppose the patch is privately maintained and the next dependency update breaks it. Who investigates, what user-facing behavior is checked, and what narrower release is possible while repair is pending? Fourth, suppose the external contribution is declined. Does the customer learn that the support plan has changed, or does a dashboard still show completion?

Fifth, suppose a human approved an earlier version but the builder regenerated the implementation afterward. Can the team find the approved version and decide what needs review again? Sixth, suppose the supplier becomes unavailable. Can the backup reconstruct the patch's purpose and the customer-facing consequences without starting from a new prompt?

Record each response as a decision and a missing capability, not a pass based on optimistic discussion. If the team cannot identify a maintenance owner, a launch depending on that patch should stay on hold or lose that feature. If origin is unknown, the relevant certification remains unresolved. If external acceptance is optional, a clear limited route may still be acceptable.

These exercises test a proposed workflow, not model intelligence. Do not publish them as evidence that an AI builder complies with COSMIC or any other community. Their value is exposing the specific obligation a demo would otherwise conceal, while there is still time to change the purchase or product scope.

10. Where this approach helps, and where it does not

Use the brief when a delivery depends on external acceptance, an unusual dependency modification, a customer's origin requirement, or a support commitment extending beyond generated files. It is particularly helpful for buyers who cannot personally inspect the technical change but can require a qualified owner and an understandable decision record.

For a disposable personal experiment using ordinary interfaces, a full brief may be excessive. Record its limited destination and avoid suggesting that it is approved for a customer or external contribution. The relevant boundary is the promised handoff and its consequences, not whether AI was present somewhere in the workflow.

The brief cannot prove rights, detect every generated fragment, force a maintainer to merge, or make an unsupported patch safe. It also does not imply that a no-LLM rule applies to using a project's software. Those questions need the actual destination, license, contract, and qualified judgment. This article establishes current policy examples and a proposed purchasing method; it reports no acceptance rate, customer savings, or experimental performance.

For today's decision, choose one dependency or customer deliverable whose support story depends on an unconfirmed external event. Ask the supplier for its destination, origin record, accountable reviewer, and refusal plan. Compare an ordinary-interface route, a supported private adaptation, and reduced scope. Approve only the route whose remaining obligations your team can actually own.

The COSMIC attention is timely because it makes that hidden obligation visible. The lasting product value is the ability to deliver something the recipient can understand and maintain under its own rules. A smaller accepted handoff can be a better outcome than a larger generated artifact that nobody has agreed to receive.

References

Sources checked October 5, 2026. Live rules can change; consult the relevant recipient before submission. The eight sources below support different parts of the argument, rather than eight reports of one event.

1. COSMIC current pull-request template: the triggering requirement and its artifact scope.
2. LLVM AI Tool Use Policy: a distinct conditional-permission model.
3. Linux kernel AI Coding Assistants: responsibility and assistance acknowledgment.
4. Developer Certificate of Origin 1.1: the certification's actual subject.
5. GitHub: Contributing to a project: proposing changes through a fork and pull request.
6. GitHub responsible-use documentation for agentic features: limitations of automated assistance and review.
7. Open Source Guides: How to Contribute: understanding the receiving community and useful contribution practices.
8. GitHub: About protected branches: technical review controls and stale approvals.