The Agentic Covenant — principles as prerequisite for adoption

[peterkc]

Context: this Discussion opens from review of #3395 — the Agentic Covenant PR by @kevglynn. The PR proposes adopting the full framework as CODE_OF_CONDUCT.md. Review surfaced a structural question better suited to this venue than a PR thread: several Covenant clauses conflict in ways the document does not resolve. Naming principles would give the framework the tiebreaker it lacks.

Scope: the framework targets multi-contributor OSS projects that accept AI-supervised contributions as a normal mode of participation — a bounded but growing class that beads itself exemplifies. The principles below are universal within that class, not across all GitHub repos.

Proposal: before the Agentic Covenant becomes binding for this project or adopted by others, name the principles that give its clauses purpose. A short principles section above the current document would provide what the framework lacks — a stable tiebreaker for clause conflicts, a compression for working memory, and an adoption anchor for downstream projects.

This thread is not a challenge to the framework's value. The clauses are thoughtful. The proposal is that principles complete the work.

What the Covenant already does well

The Covenant stakes out a novel position in OSS governance. Existing policies fall into two camps — restrictive (pip, NetBSD, Gentoo, curl) or permissive-with-disclosure (Linux kernel, QEMU, Ghostty). The Covenant proposes a third: agent-affirmative with full governance.

The integration is genuinely novel:

• Principal-agent accountability — the human operator who deploys an agent bears responsibility for its actions. Enforcement targets the operator, not the agent or the account.
• Disclosure Safe Harbor — contributions that disclose AI assistance (via Assisted-by:) receive the same quality of review as non-disclosed ones. Differential treatment based on disclosure is itself a conduct violation.
• Per-principal rate limits with circuit breakers — per-operator contribution caps (3 open PRs, 5 per day, 72-hour cool-down after close-without-merge) plus hard stops after 3 automated agent iterations on the same resource.
• Modular adoption kit — Parts I–VI with explicit dependencies, CC BY 4.0 licensed so downstream projects can adopt the whole framework or selected parts.

Individual clauses have precedent (Linux kernel's Assisted-by, LinkML's "understanding over authorship," Contributor Covenant's graduated enforcement, OWASP Agentic AI Top 10). The integration is the contribution.

What the framework is missing

The Covenant's clauses describe what is allowed and what is not. Principles describe why.

Without named principles, three clause conflicts have no stable resolution:

• Safe Harbor vs. maintainer discretion (Part II L63–67). The Safe Harbor protects disclosed contributions from differential treatment; the discretion clause preserves maintainer authority over merge decisions. Both address the same situation. Today, which wins depends on whose reading prevails.
• Rate limits vs. crunch-period contribution (Part II L71–78). A dedicated contributor legitimately exceeding the 3-open-PR / 5-per-day caps during a release cycle — is that stewardship failure, or principle alignment?
• First-mover priority vs. stub PRs (Part IV L110–118). First-mover priority gives the earliest open PR on an issue the right to merge; the clause also excludes "stub or placeholder PRs" from establishing priority. By what criteria does a PR qualify as substantive enough to claim first-mover standing?

Named principles resolve these stably. Clause-level arbitration resolves them case-by-case, inconsistently, every time.

Principles also simplify adoption. A downstream project currently accepts every clause as written or forks. With principles, the project adopts five stable values and configures clauses (rate-limit numbers, enforcement team size, appeals process) to its scale.

A third gap worth naming: the Covenant names accountability but not credibility. Community practice uses vouching and reputation as the primary quality lever — Linux kernel's Reviewed-by: and Tested-by: trailers, Rust's RFC-sponsorship requirement, established-contributor trust in most active projects. The Covenant's current model treats every accountable operator as equally trusted, which is not how OSS actually works at scale.

The five principles

P1: Accountability — Every agent action has a named human owner. Agents are tools; enforcement targets the operator.

P2: Transparency — Disclosure is honored, not punished. Assisted-by disclosure is required; disclosed contributions receive the same review as non-disclosed.

P3: Merit — Contributions are judged on their output. Tool use neither diminishes nor enhances evaluation.

P4: Priority — First substantive contribution has right-of-way. Speed does not determine merge order.

P5: Stewardship — Contribution volume is bounded by review capacity. Rate limits and circuit breakers keep review tractable.

Narrative

AI-supervised contributions need a human owner. Owners are accountable when the work is transparent. Transparency works because contributions are judged on merit. Merit protection requires priority for those who contribute first. Priority is sustainable only when volume respects the community's capacity to review.

Accountability. Transparency. Merit. Priority. Stewardship.

Hierarchy

P1: Accountability  -->  P2: Transparency  -->  P3: Merit
|________________ core values: non-negotiable ________________|

P4: Priority  -->  P5: Stewardship
|________ operational: defers to core ________|

Inner ring wins when principles conflict. Within a ring, conflicts are typically rare — principles in the same ring are complementary.

Conflict resolution

• Safe Harbor (P2/P3) vs. rate limits (P5) → P2/P3 wins. A high-quality disclosed contribution is not rejected for exceeding a rate limit.
• Accountability (P1) vs. priority (P4) → P1 wins. First-mover does not insulate an operator from accountability.
• Merit (P3) vs. stewardship (P5) → P3 wins. Volume limits do not override quality judgment.

What this unlocks

With principles named, the clause-level calibration questions become tractable:

• Safe Harbor's comparative-evidence clause serves P3 (merit) and P5 (stewardship) — bounded to what stewardship warrants, without imposing statistical obligations on small teams.
• Rate limits become P5 parameters tunable by adopters — the principle is stable, the numbers are local.
• Enforcement infrastructure (Part V) scales to adopter capacity without violating P1 — a solo maintainer implements accountability differently from a three-team project, but the principle holds.

A follow-up thread can work through each Part's calibration with the principles in place.

Adoption sequence

1. Resolve principles (this thread).
2. Revise clauses with cross-references to principles served: Part II → P1 + P2. Part III → P1. Part IV → P3 + P4. Part V → P5.
3. Per-adopter configuration of Parts II and V.
4. Parts I, III, IV adopt as written.

What this Discussion should accomplish

Two outcomes would complete this stage:

1. Agreement (or a counter-proposal) on the five principles above.
2. Direction on whether the principles section ships from this repository or from a dedicated framework repository.

With principles settled, a follow-up thread can address clause-level calibration, and Parts III and IV can adopt cleanly as-is.

Sources

• Principles-based OSS governance precedent: Apache Way, Debian Social Contract, Kubernetes values — established pattern the Covenant extends into the AI-agent domain.
• Anthropic safety hierarchy — ranked-framework precedent (safe > ethical > policy > helpful).
• Contributor Covenant v2.1 — community-standards baseline the Covenant extends.
• Linux kernel coding assistants policy — Assisted-by attribution convention.
• LinkML AI Covenant — "understanding over authorship" precedent.

---

cc @kevglynn @maphew @turian — opening this in parallel with #3395. Earlier comments on that thread flagged the structural angle worth working through here.

[kevglynn]

@peterkc — this is a serious read. You're right that v1.1's Preamble names three principles but the rest of the document doesn't use them, so clause conflicts get settled ad-hoc. Named principles on top would fix that, and it's a cheap change. I think we should do it. Below: where I'd push back, one gap to flag, and a counter-proposal on the principle set.

Where I agree

Principles above clauses. Accepted. The precedent you cited (Apache Way, Debian Social Contract, Kubernetes values, Anthropic's safety hierarchy) is real, and the two-ring structure — core non-negotiable, operational defers to core — makes sense. Without it, Part II L63–67 and Part IV L110–118 get settled case-by-case.

The credibility observation is the sharpest thing in your comment. v1.1 already allows differential trust in a few places (the "authorized project bots" exemption, Maintainer Discretion, "pattern of differential treatment" as the enforcement trigger) but doesn't name reputation as a legitimate review lever anywhere. We should say so explicitly. My proposal's below — as a Part II clause, not a principle, for reasons I'll get to.

Adoption anchor. Principles-first gives downstream projects a stable set to agree on and clauses to tune. That's easier than the current "adopt verbatim or fork" choice.

Where I'd push back

1. One of your three conflicts is a doctrinal change framed as a clarification.

Safe Harbor vs. Maintainer Discretion — real interpretive gap, agreed. First-mover vs. stub PRs — cleanest of the three; "substantive engagement" (L118) is undefined, and P3/P4 would close it. But rate limits vs. crunch-period contribution isn't actually unresolved in v1.1 — the cap is the cap, and adopters tune the numbers. Your proposed resolution ("a high-quality disclosed contribution is not rejected for exceeding a rate limit") doesn't stabilize the existing text; it overrides it. Rate limits become advisory whenever a reviewer judges a PR high-quality, which is most situations where someone argues to bypass the cap in the first place.

If we want to say merit beats stewardship at the ring level, let's say that explicitly and accept what it costs (cap enforcement becomes interpretive). I don't think we should — the caps are enforceable precisely because they're mechanical — but it's a real design choice, not a tiebreaker. That's the one place I'd push back.

2. The mutual-obligation framing needs to survive the merge.

v1.1's stress test specifically added a bilateral frame: contributors owe accountability, quality, and transparency; maintainers owe merit-based review, Safe Harbor, fair process. Your five principles break that apart — Merit and Stewardship sit in separate principles, and the lexical order puts Merit above Stewardship. That tilts the deal: contributors get merit protection as a "core, non-negotiable" right; maintainer capacity limits get demoted to "operational." That's not a neutral rearrangement; it shifts the balance v1.1 was trying to keep.

The fix is mechanical — tag each principle with whose obligation it binds. Five principles, one deal. See structure below.

3. P4 Priority is shakier as a principle than as a rule.

First-mover priority is an anti-racing mechanic. Elevating it to principle rank puts it on par with accountability, which it isn't. I'm open to including it if we scope it narrowly — something like "Priority — where contributions race, substantive first entry has right-of-way" — but I'd resist it reading as a freestanding value on par with Accountability or Merit.

4. Two principles are missing from your five.

Welcome. The Covenant's most novel commitment — AI-supervised contributions are a legitimate and valued way to participate; differential treatment based on tooling is a conduct violation — disappears from your set. Your P3 Merit ("judged on output; tool use neither diminishes nor enhances") is neutral-sounding, which is a demotion. No other OSS document says what v1.1's Principle 3 says explicitly, and without naming it as a principle, a future amendment could weaken it without violating any of P1–P5. It should be a named principle.

Safety. Prompt injection, data leakage, "poisoning the well," adversarial content, security-sensitive pre-submit review — these are in the operative text of the Covenant but map to none of your five principles. A security incident would have no principle to point to. Either it needs its own principle or it belongs inside Stewardship (which I'd expand).

5. Credibility should be a mechanism, not a principle.

You flagged the reputation gap and declined to add a sixth principle for it. I think I know why: "Credibility" would directly collide with P3 Merit ("judged on output"). Linux's Reviewed-by:/Tested-by:, Rust's RFC sponsorship, and Kubernetes OWNERS files are explicitly differential trust based on history — the opposite of output-only evaluation.

The fix is to scope it: reputation attaches to the principal, not to tooling, and not (yet) to the agent. That keeps the Safe Harbor intact (you can't differentially weight disclosed-vs-undisclosed) while acknowledging what every serious OSS project actually does. Concrete proposal below.

Counter-structure: six principles, bilateral tags, credibility as mechanism

Taking what you proposed and folding in what v1.1 currently commits to:

#	Principle	Binds	Ring
P1	Accountability — every agent action has a named human owner; enforcement targets the principal, never the agent	Contributor	Core
P2	Welcome — AI-supervised contributions are legitimate; differential treatment based on origin or tooling is a conduct violation	Maintainer	Core
P3	Merit — contributions judged on output; contributors owe quality, maintainers owe fair review regardless of how code was produced	Shared	Core
P4	Transparency — disclosure is required where material, protected where given, and never penalized	Shared	Core
P5	Priority — where contributions race, substantive first entry has right-of-way; speed of production does not determine merge order	Maintainer	Operational
P6	Stewardship — contribution volume is bounded by the community's capacity to review; safety constraints (prompt injection, data leakage, adversarial content) are non-negotiable	Contributor	Operational

Hierarchy

P1: Accountability  -->  P2: Welcome  -->  P3: Merit  -->  P4: Transparency
|_________________  core ring: non-negotiable  _________________|

P5: Priority  -->  P6: Stewardship
|______  operational: defers to core  ______|

Binds:  P1/P6: Contributor   |   P2/P5: Maintainer   |   P3/P4: Shared

Core ring wins when rings conflict. Within the core ring, the principles cover different obligations, so internal conflicts are rare — where they do surface, the document resolves them at the clause level. The Binds row shows the bilateral deal — contributor and maintainer obligations mirror across rings, so neither side's obligations get demoted to operational status alone.

What this preserves from your proposal: principles-above-clauses, two-ring hierarchy, five of six principle names, the adoption-anchor function.

What this recovers from v1.1: explicit welcome stance (P2), bilateral deal via "Binds" tags, safety commitments (folded into P6).

What this refuses: treating rate-limits-vs-merit as something the ring hierarchy resolves — it's a design call, not an interpretation call.

The credibility clause (as Part II addition, not a principle)

After the Maintainer Discretion paragraph in Part II:

Reputation and review trust. The Safe Harbor prohibits differential treatment based on how a contribution was produced. It does not displace community practices that weight review trust based on a contributor's demonstrated track record — including Reviewed-by: / Tested-by: trailers, sponsorship requirements, and tiered reviewer/approver roles. Such practices remain compatible with this Covenant when (a) they attach to the principal, not to disclosure status or tooling choice; (b) the criteria and roles are documented; and (c) they do not create a two-tier Safe Harbor in which established contributors' AI-assisted work is protected but new contributors' is not. The principal's reputation — not the agent's — governs review trust. Whether agents should accrue portable reputation (model-level or instance-level) is deliberately left open and flagged for v2.0.

This fills the gap you identified, keeps the Safe Harbor tool-neutral, doesn't commit to agent-level reputation yet, and flags the v2.0 question rather than pretending we've solved it.

The "show it working on a scenario" challenge

You're right that a principles section is only doing work if it resolves cases the clauses alone can't. Three scenarios against the proposed six:

Scenario A. A new contributor submits a PR that declares Assisted-by: Claude and overlaps a PR from an established contributor who submitted three hours earlier with no disclosure. Both are substantive. Who merges?

• Clause reading alone: Part IV First-Mover Priority favors the established contributor; Part II Safe Harbor says disclosure can't be used against the new contributor.
• Principle reading: P5 Priority (maintainer obligation, operational) defers to P2 Welcome and P4 Transparency (core). First-mover wins only if the decision process would look the same absent the disclosure. If it wouldn't, P2/P4 override.

Scenario B. An established contributor consistently opens PRs at the 3-open cap, all high-quality, during a release crunch.

• Clause reading alone: rate limits say cool down; quality says merge.
• Principle reading under your hierarchy: Merit (P3, core) overrides Stewardship (P6, operational) — bypass the limit.
• Principle reading under my counter: P6 Stewardship is operational, but its safety and capacity constraints aren't interpretive. The resolution is at the clause level — the adopting project adjusts the numbers if they're wrong for this scale, or declines to. The principles don't resolve this one, because it shouldn't be resolved at the principle layer.

Scenario C. An operator's agent produces a PR with a prompt-injection payload in a comment.

• Clause reading alone: Part I unacceptable behavior list covers it.
• Principle reading under your hierarchy: no principle lives here; the clause is orphaned.
• Principle reading under my counter: P6 Stewardship's safety clause is the anchor. The principal (P1) is accountable; the payload violates P6.

B is the one your hierarchy and mine produce different answers on. That's the doctrinal call that should be made explicitly.

On the home-of-the-framework question

Stay in beads for now. Extract on signal, not on plan.

Contributor Covenant lived in Coraline Ada Ehmke's personal repo through v1.x; contributor-covenant.org and the Organization for Ethical Source came after thousands of adoptions. LinkML's AI Covenant still ships from linkml/linkml and nobody considers that a weakness. Premature extraction into a dedicated "framework" repo with no adopters gets you infrastructure overhead and a README that reads like vaporware next to beads, which looks like the real thing.

What I'd do:

• Now (0–3 mo): resolve principles here, in this thread. Add a version header (Agentic Covenant v1.x, CC BY 4.0, commit link) so early adopters can cite a specific version. Reserve the agentic-covenant org name defensively and leave it empty.
• On signal (3–12 mo): when 3–5 external projects adopt substantial portions, execute a hybrid — canonical stays in beads, mirror to a dedicated agentic-covenant repo for adoption kit + versioned site. Beads becomes the reference implementation.
• AAIF / AGENTS.md: companions, not competitors. AGENTS.md is a file format (what agents read); the Covenant is governance (what humans-with-agents must do). Propose formal liaison when we extract; don't donate IP yet.

Concrete next steps for this thread

1. Agreement on the six-principle set with obligation tags (or a counter).
2. Decision on P5 Priority — operational principle, or remains a Part IV rule only?
3. Decision on the reputation clause above (or a counter).
4. Resolution on rate-limits-vs-merit: is this a ring-hierarchy tiebreaker (your proposal) or a doctrinal call that keeps the caps enforceable (my proposal)?
5. Home question: deferred until adoption signal — does that work?

Rate-limits-vs-merit and any per-clause principle cross-references can go to a follow-up thread. Let's not bundle the doctrinal change with the structural clarification.

Tactical note: the PR-level concerns you raised on #3395 are being addressed in parallel — engineering commits split to #3436 as a non-destructive starting move, version inconsistency fixed, rate-limit tracking clarified as project-level choice, and the email / enforcement-team questions deferred to maintainers. The remaining PR structure (your B/C/D options) is open for maintainer input. Your parts-mapping observation ("III and IV adopt as-is; II and V depend on principles work") is the right carve-up regardless of which PR shape lands; whatever this thread produces will need incorporation into Parts II and V.

Thanks for the depth on this.

[kevglynn]

@peterkc ...taking stock: I think we agree on everything except rate-limits-vs-merit -->

Your two-ring hierarchy is the right frame; I'm using it directly.

Want to hash out that one question, and I'll draft the principles section from there?

[kevglynn]

Picking this back up. On May 3 I said I'd draft the principles section once we'd settled the frame — here it is. Two things shifted since: I think the rate-limits/merit question has a cleaner resolution than either of us had, and your "credibility" gap has a clean home. Full drafted section is in a gist (link at the end); the load-bearing parts are below.

The rate-limits / merit question

I'd stopped framing this as "design call vs. tiebreaker" — that framing was the problem. Merit and Stewardship answer different questions: Merit decides what merges; Stewardship decides the rate at which new work enters the review queue. They can still touch the same contributor's outcome, so the boundary has to be drawn explicitly rather than assumed. The Covenant draws it by constraining rate limits to be mechanical, public, bounded, disclosure-neutral, and appealable:

• A reviewer can't waive a cap by calling work "high quality" (quality isn't the question a cap asks) — and can't tighten one because work is AI-assisted. That's what keeps caps enforceable instead of advisory.
• Work over the cap is queued, not silently refused — but only where there's a visible queue state and a bounded path to admission, a written capacity explanation, or an appealable closure. "Queued" must never decay into indefinite non-review; that's just rejection wearing a process hat.
• Cool-downs and circuit breakers attach to the burden that triggered them, not to the principal as a person — they can't auto-block an unrelated, ready PR.
• Crunch capacity is handled by raising the parameter under content-neutral, published criteria (with a conflict-of-interest rule so a maintainer can't exempt their own agent), never case-by-case bypass.

This keeps caps mechanical — my concern — while making sure Stewardship can throttle rate but never become a quality veto or a Safe-Harbor backdoor, which I think was the real worry under your "Merit wins" position. So I think we both get what we were actually protecting.

One note on the Anthropic hierarchy you cited: it cuts toward this shape, not toward strict ranking. The constitution says the ordering is "holistic rather than strict" — higher priorities "generally dominate" but are weighed in an overall judgment "rather than only viewing lower priorities as 'tie-breakers'" — and it pulls genuine non-negotiables out as separate hard constraints, exempt from the weighing. That's the same shape here: Safety sits outside the rings as a floor, and Merit-vs-Stewardship isn't settled by strict rank ("Merit is core, so it wins") but by what each principle actually governs.

The principle set

Built on your two-ring hierarchy, used directly. I landed on five, not six — your instinct on leanness was right, and so was the precedent: Contributor Covenant's verbatim-adoptability came from staying small.

#	Principle	Ring
P1	Accountability & Safety — a named human owner answers for the agent's conduct and its safety; no prompt-injection, data-leakage, or adversarial payloads, and security-sensitive changes get human review before submission	Core
P2	Welcome — agent-assisted contribution is legitimate and valued; differential treatment based on origin or tooling is a conduct violation	Core
P3	Transparency — material AI involvement is disclosed (Assisted-by); required where material, protected where given, never penalized	Core
P4	Merit — judged on output; contributors owe quality before submission, maintainers owe fair review regardless of how the work was produced	Core
P5	Stewardship — contribution volume is bounded by review capacity; rate limits govern the rate at which new work enters the review queue, not whether work merges	Operational

Core ring wins on any cross-ring conflict; order within the core ring is narrative, not rank.

Three deltas from your original five:

• Welcome is named. Your P3 Merit was neutral — "tool use neither diminishes nor enhances" — which lets a project judge purely on output and still ban AI work outright. The anti-discrimination teeth need their own home, and "Welcome" is the one commitment no prior OSS CoC makes explicitly.
• Safety is in P1 and surfaced in the name (Accountability & Safety). I'd considered folding it into Stewardship — that was wrong; a Severe-weight harm floor can't hang off an operational principle that defers to core, or an operator could argue "blocking my agent's payload is tooling-based differential treatment, and Welcome is core." It belongs at the core.
• Credibility becomes a Stewardship mechanism, not a principle. Reputation attaches to the principal (not tooling, not the agent), changes review order and depth above a published baseline but never eliminates baseline review for newcomers and never touches the merge standard. A standalone "Credibility" principle would collide head-on with Merit; scoped as a mechanism, it does what Linux's Reviewed-by:/Tested-by:, Rust's RFC sponsorship, and Kubernetes OWNERS already do. Portable agent reputation is left open and flagged for v2.0.

The one structural call still open

Is Priority a principle, or a Part IV clause? You had it as P4. I've put it back in Part IV as a first-mover rule grounded in Merit — first substantive entry has right-of-way; speed doesn't set merge order — rather than a value ranking beside Accountability and Merit, which matches the read I floated in April that it's "shakier as a principle than as a rule." I lean clause, but I'm genuinely open; if you or @maphew / @steveyegge think it earns principle rank, say so and I'll lift it.

On the home question — agreed: stay in beads, extract on adoption signal, not on plan. No change there.

Full drafted section — preamble, the Stewardship scope clause, the reputation mechanism, and a worked table showing each conflict you flagged resolving: https://gist.github.com/kevglynn/9928d26be483afa504b23ad656712d93

Genuinely open to other opinions on any of it — the count, the Priority call, or the crux framing.

[maphew]

heyo. I'm dropping this quick note to say I have no opinion at this time. My initial read says this is a topic that merits thinking about, conjoined with: I haven't time for thinking on this (so far). So don't interpret silence on my part to be disagreement. (that might come, I just don't know yet ;- )