Open source trust: a public badge and evidence chain so contributors and users can see how agent contributions are reviewed

Last reviewed 2026-08-21 · 8 min read

Open-source projects now receive a growing share of pull requests written by AI agents, and users want to know how those are reviewed before they depend on a release. A public, verifiable evidence chain and a free trust mark show exactly that — agent authorship, human review, tests, sealed releases. Project governance and licensing stay the maintainers' own.

What it is

Open-source maintainers are on the front line of AI-assisted development. Pull requests arrive written partly or wholly by coding agents; some are excellent, some are plausible nonsense, and the maintainers’ review is the only thing between them and the release everyone downstream depends on. Users, in turn, now ask a question that used to be unthinkable about a popular library: how much of this was written by an AI, and did a human actually look at it?

Trust in open source has always rested on visibility — the code is public, the history is public, the review is (usually) public. What is not visible in the standard tooling is authorship by agent versus human, and the link between an agent’s contribution and the human review that accepted it. git records the committer; it does not record that the committer’s change came out of an agent session, nor which agent, nor who reviewed it with that knowledge.

A public evidence chain makes that visible: every change recorded with its actor — human or agent, with tool and model — the review that accepted it, the tests that ran and the releases it shipped in, in an append-only, time-anchored record anyone can export and verify with an open-source verifier. The trust mark is the public face of it: a free badge that links to the project’s verification page and shows green only while the chain verifies — earned, never assumed, and honest when it is not.

Who it applies to and when

Maintainers of open-source projects — libraries, frameworks, tools — especially those with a meaningful volume of agent-written contributions, or whose users are commercial organisations with their own documentation duties. Foundations and stewards who set contribution policy. And downstream: the companies that embed open-source software in products and have to document what they depend on.

No date applies to non-commercial open source directly, and the Cyber Resilience Act deliberately keeps most of it outside its scope, with a lighter regime for open-source software stewards; the full regulation applies from 11 December 2027 to those who place products with digital elements on the market — which includes companies shipping open-source components inside commercial products. Those downstream users are the ones who will ask maintainers for evidence, because they need it for their own documentation. The Product Liability Directive, from 9 December 2026, likewise leaves free and open-source software supplied outside a commercial activity outside its scope — and likewise bites whoever commercialises it.

This topic is not part of our regulatory mapping — open-source trust is a community and supply-chain use of development evidence. The support section uses the mapping’s vocabulary and says what the record does and does not claim.

What it asks of your development process

For a maintainer, the asks are light in effort and heavy in honesty:

Record agent contributions as agent contributions. Contributors using agents carry tool, model and session in their commit trailers — a contribution-guideline line, not a tooling project. Each lands as an agent-authored change.
Record the review. The maintainer’s acceptance of a pull request is the human review that matters; it lands as a review decision linked to the change, with the maintainer’s pseudonymous identity.
Let CI evidence itself. Test runs land as test evidence per change.
Seal releases. A tagged release becomes a sealed segment with an SBOM and licence snapshot — the thing a downstream company actually needs for its own documentation.
Publish the verification page and the badge. The page is public; the badge is free; export is free forever. Anyone — a user, a downstream vendor’s auditor — can verify the chain without trusting the project or us.

What the project gains is not a seal of approval but legibility: a user deciding whether to depend on a release can see the share of agent- authored changes, whether they were reviewed, and what tests ran — and verify it. What the project avoids is the two bad answers to “how do you handle AI contributions”: “we don’t know” and “trust us”.

The honest limits: the record shows review happened, not that it was thorough; it shows tests ran, not that they were sufficient; and it shows the repositories and events the project records, nothing else. The badge says “software evidence by OLOBOLO” — and it is wording we never change to a claim of approval.

For maintainers the quiet benefit is workload. “How do you handle AI contributions?” arrives in issues, in security questionnaires from corporate users, and in conference hallways; answering it once, with a public record that updates itself, replaces answering it forever by hand. It also changes the tone of the conversation with contributors: a guideline that says “declare your agent in the trailer” is lighter and fairer than one that says “no AI”, and it is enforceable by evidence rather than by suspicion. The project states its policy, the record shows it in practice, and users decide with their eyes open.

What OLOBOLO evidence supports

OLOBOLO records changes with their actor (human or agent, with tool and model), review decisions, test evidence and sealed releases, exposes a public verification page per organisation and repository, serves a free trust mark that reflects the chain’s verified state, and keeps export free for everyone. The table uses our mapping vocabulary; this is not a regulatory mapping — project governance, licensing and contribution policy are the maintainers’ own.

Community question	What you need to show	Chain evidence	Support
How much of this project is written by AI agents?	Agent-authored share of changes, measured	`change.authored` with actor type, tool, model; AI-share figure on the verification page and per release	Supports
Are agent contributions reviewed by a human before release?	Maintainer acceptance linked to each agent-authored change	`change.reviewed` linked per change; review-coverage figure	Supports
What is in a release, and can I verify the record myself?	Sealed releases with components; a verifiable public chain	`release.sealed` + SBOM and licence snapshot; public verification page; export + open-source verifier; RFC 3161 anchors	Supports
Is the trust mark honest about the state?	Green only while the chain verifies; neutral otherwise; never a claim of approval	Badge state model: verified is earned and losable; wording frozen	Supports
Contribution policy, code of conduct, licence choice, security disclosure process, build provenance (e.g. SLSA)	Project governance and build-integrity frameworks	—	Out of scope

Build-integrity frameworks such as SLSA are complementary, not covered: they attest how an artifact was built from a source; the chain records how the source came to be.

Evidence, not a legal opinion: this maps what the chain supports as documentation — the project’s own governance decides what trust requires.

How to start

Install the recorder on the project’s repositories — free for open source — and add one line to CONTRIBUTING: contributors using AI agents carry tool, model and session in commit trailers.
Let maintainers’ merges be the review. Acceptances land as change.reviewed; CI runs as test.evidenced; tag releases to seal them with an SBOM.
Publish the verification page and the badge. Put the free trust mark in the README, linked to the public page; it earns green as the chain verifies and turns neutral if it ever stops.
Point downstream users at the export. Companies embedding the project can verify the chain themselves and cite it in their own documentation — which is how open-source trust propagates.

Evidence can't be reconstructed after the fact — it has to be recorded while you build. Start recording now, free, and every change from this moment is on the record.

Start recording

Frequently asked questions

Is the trust mark free for open-source projects?

Yes. Open-source projects get the badge and the chain free — distribution is the point. The mark always links to the project's public verification page and shows green only while the chain verifies.

Does the badge mean a project is safe or meets some standard?

No, and it never says so. It is evidence: that the project records how changes are authored, reviewed and tested, and that the record verifies. Whether the project is safe to depend on is the user's judgement, informed by the record.

How does this relate to SLSA and build provenance?

They are complementary. SLSA attests how an artifact was built from a source; the OLOBOLO chain records how the source came to be — who or what authored each change and who reviewed it. A project can publish both.

What about the CRA's open-source provisions?

The CRA largely leaves non-commercial open-source development outside its scope, with a lighter steward regime; once software is monetised or integrated into a commercial product, the usual duties apply to whoever does that. A public chain helps downstream commercial users document what they depend on.

Sources

Last reviewed 2026-08-21. Dates are cross-checked against our regulatory mapping and radar.

A necessary honesty: OLOBOLO is evidence, not a legal opinion. This guide describes what our chain supports as documentation — Supports / Partially supports / Out of scope — and your counsel decides what compliance requires. No tool can promise the latter.