Rebalance gatekeeping framing with builder-commons ethos from manifesto

[JohnRDOrazio]

Updated 2026-05-02: PR #9 has merged. File paths below have been updated to reflect the post-merge repo structure — the former ai-governance/ai-vetting-criteria.md content is now part of project-governance/project-vetting-criteria.md as "AI domain extension" subsections, and the ai-governance/ research memos have moved to research/ with broadened (non-AI-specific) scope.

---

Context

An audit of all repo documents against the CDCF bylaws and manifesto found a systemic framing issue: the documents present the CDCF primarily as a gatekeeper, while the manifesto describes a builder commons.

Problem

The manifesto describes the CDCF as a "builder commons" dedicated to "aggregating, vetting, and communalizing open-source digital tools" with the aim to "professionalize the ecosystem" so that "local innovations become global resources."

The repo documents frame the CDCF almost exclusively as a gatekeeper:

• Projects are "submitted," "evaluated," and seek "endorsement"
• The vetting criteria are gatekeeping frameworks describing what keeps tools out
• The relationship is one-directional: CDCF publishes standards, institutions consume/extend

Missing from the documents:

• How the CDCF helps submitted projects improve to meet criteria (the builder-support role)
• How local innovations are generalized into global resources (the communalizing function)
• The peer review and documentation support the manifesto envisions
• The bidirectional commons model where institutions contribute innovations upward

The research/fragmented-catholic-digital-governance.md memo (formerly ai-governance/fragmented-catholic-ai-governance.md) is particularly affected: in its AI case study it frames Catholic institutions as consumers of commercial AI, never builders — directly contradicting the manifesto's producer/builder vision.

Suggested approach

• Add language throughout about the CDCF's role in helping projects improve and succeed, not just evaluating them
• Describe the bidirectional flow: institutions contribute to the commons, not just consume from it
• In the fragmentation memo, acknowledge that Catholic institutions can and should build digital tools (including AI), not just evaluate vendor offerings
• In the README, balance the evaluation/endorsement language with the aggregating/communalizing mission
• Consider adding a "Builder Support" or "Commons Contribution" section to the lifecycle document

Affected files

• README.md
• project-governance/lifecycle.md
• research/fragmented-catholic-digital-governance.md
• project-governance/project-vetting-criteria.md (including AI domain extension subsections)
• research/governance-as-code-catholic-technology.md

Dependencies

Should be implemented after #8 / PR #9 is merged. ✅ PR #9 merged 2026-04-19.

Identified during bylaws/manifesto alignment audit.

[JohnRDOrazio]

Additional topic: Dedicated open-source license for Catholic technology projects

Beyond rebalancing the framing, there is a deeper question about whether the CDCF should develop a dedicated open-source license tailored to Catholic technology projects. This requires careful evaluation of whether such a license would serve the commons mission or create greater fragmentation with existing open-source licenses.

The domain problem

The CDCF's chartered scope spans multiple categories with fundamentally different licensing needs:

1. Software tools

Standard open-source licenses (MIT, Apache 2.0, GPL, etc.) likely work well here. A custom license might create unnecessary friction and fragmentation.

2. Catholic data under ecclesial governance

Some Catholic data cannot be open-sourced in the traditional sense. For example, vernacular translations of Bible editions are subject to copyright held by bishops' conferences or publishers under ecclesial authority. The data itself falls under the jurisdiction of ecclesial bodies.

Could a Creative Commons license work here? Possibly — CC licenses are designed for content rather than software, and variants like CC BY-NC-ND could restrict commercial use and derivative works. But the key constraint is that the licensing authority for this data rests with the ecclesial body, not the CDCF. The CDCF's role would be to steward and distribute such data under whatever terms the competent ecclesial authority grants.

3. Shared standards for structuring Catholic data

This is where a custom or carefully chosen license may be most needed. A shared standard for structuring Catholic data (e.g., CMDDR, CRMETDR, CLEDR from standards/overview.md) has specific requirements:

• It should be open enough for Catholic institutions and developers to implement freely
• It should not be so permissive that a third party — neither representing an ecclesial body nor the CDCF — can adapt the standard for the purposes of structuring or distributing Catholic data outside the governance framework
• The standard's integrity must be protected: implementations should conform to the standard, not fork it

Existing licenses that might be evaluated:

• ODbL (Open Data Commons Open Database License) — designed for data, requires share-alike
• CC BY-SA — share-alike protects against ungoverned forks, but may be too permissive on adaptation
• W3C Document License / OASIS standards license — designed specifically for technical standards with implementation rights but restricted modification of the standard itself
• A custom CDCF Standards License that grants implementation rights while reserving the right to define and modify the standard to the CDCF and competent ecclesial authorities

Key questions to evaluate

1. Would a dedicated CDCF license favor the commons mission by clearly protecting Catholic data governance, or hinder it by creating fragmentation and adoption friction?
2. Is a single license feasible across all domains, or does the CDCF need a licensing framework with different licenses for software, data, and standards?
3. For standards specifically: how do we balance openness (encouraging adoption) with governance (preventing unauthorized adaptation for Catholic data distribution)?
4. What is the relationship between ecclesial copyright/jurisdiction over Catholic data and the CDCF's stewardship role in licensing terms?

This topic likely warrants its own dedicated discussion or working group, but it is closely related to the builder-commons framing question since the choice of licensing model shapes what kind of commons the CDCF actually becomes.

[mj3b]

Response to Discussion #17: Rebalancing the Vetting Framework

Submitted by Mark Julius Banasihan, TAC, AI Governance
In response to the bylaws/manifesto alignment audit opened by Fr. John R. D'Orazio, April 17, 2026

---

1. Where the Audit Is Accurate

Having read the manifesto, the bylaws, the live governance site, and all five affected documents, the audit holds in three specific places.

Document	Confirmed gap
ai-vetting-criteria.md	Default language is "submitted," "evaluated," "endorsed": evaluator vocabulary, not accompanier vocabulary. The open framing in "An Invitation to Iterate" appears only at the end, where it reads as appendix rather than frame.
fragmented-catholic-ai-governance.md	Catholic institutions appear exclusively as deployers of existing tools responding to vendor proposals. The word "builder" does not appear. The manifesto's producer/builder vision is absent.
README.md	The communalizing function appears in the purpose statement and disappears from the description of how projects move through the process.

One important qualification on scope: project-types.md, deployed in v0.2, already contains this sentence:

"The CDCF's vetting process is designed to be transparent, supportive, and accessible. It is a service to the community, not a gatekeeping mechanism."

The builder-commons framing already exists in the published governance documents. The vetting criteria and the fragmentation memo have not caught up to it. The fix is alignment, not invention.

---

2. The Manifesto Supplies the Language

The manifesto's "Builder's Mandate" section provides the anchor text the revised documents need:

"Our mission is to aggregate, vet, and communalize these gifts... By providing institutional credibility, rigorous peer review, and shared documentation, we ensure that local ingenuity becomes a global resource."

And the scriptural grounding:

"According to the grace of God given to me, like a wise master builder I laid a foundation, and another is building upon it." (1 Corinthians 3:10)

The vetting criteria preamble should open from this passage directly, not introduce vocabulary from outside the manifesto. A diocese-level reader who comes to the repository through the manifesto should hear the same register in the criteria document.

---

3. Specific Changes by File

The eight criteria stay as written. What changes is the relationship the CDCF holds with a builder working toward them, and the explicit presence of the peer review and documentation support the manifesto describes.

File	Change
ai-vetting-criteria.md	Move "An Invitation to Iterate" framing into the Purpose and Rationale section. Add one paragraph before the gate table establishing CDCF's accompanier role: peer review support, documentation assistance, and formation toward the criteria. Judgment at the gate is the final step, not the defining one. A project that does not clear Gate 1 on first submission has identified where formation work remains.
fragmented-catholic-ai-governance.md	Add a builder case study alongside the three-diocese deployer cases. A Catholic institution that builds an original tool in Diocese A cannot get it adopted in Diocese B without a shared standard to evaluate it against. This is a stronger version of the fragmentation argument than the memo currently makes, and it correctly frames Catholic institutions as producers alongside consumers.
project-governance/lifecycle.md	Add a "Builder Support" description to each lifecycle stage. Name what CDCF does with a project at each gate: mentorship, peer review, documentation support, canonical guidance. The project's obligations are already documented; the CDCF's reciprocal commitments are not.
README.md	Add one paragraph before the two-gate framework description naming the bidirectional model: institutions contribute innovations upward; CDCF accompanies, reviews, and communalizes them.
ai-governance/governance-as-code-catholic-ai.md	Add a section framing governance-as-code as a formation tool. The architecture helps Catholic institutions reach the standard; it also records whether they reached it. The current document covers only the second function.

Language replacements across all affected files:

Current	Proposed
"submitted for evaluation"	"enters a formation pathway"
"endorsed" / "received endorsement"	"recognized as commons-ready"
Gate = judgment point	Gate = formation milestone
Catholic institutions as deployers	Catholic institutions as builders and deployers

---

4. On the Licensing Question

Fr. John's follow-on comment identified the right structure: the CDCF's chartered scope spans three categories with different licensing requirements, and a single license cannot serve all three.

Category	Licensing consideration
Software tools	Standard open-source licenses (MIT, Apache 2.0) are sufficient. A custom license creates adoption friction without governance benefit.
Catholic data under ecclesial authority	Licensing authority rests with the competent ecclesial body. CDCF's role is stewardship under terms the ecclesial authority grants. CC BY-NC-ND is a candidate for cases where the ecclesial body delegates distribution rights to CDCF.
Shared standards (CMDDR, CRMETDR, CLEDR)	This is where a carefully chosen license matters most. The core tension is implementation freedom against standard integrity: institutions need to implement freely, but ungoverned forks fragment the standard. ODbL, W3C Document License, and the OASIS standards license each address parts of that tension and warrant evaluation before any custom instrument is drafted.

The single-license question resolves once the three categories are separated. A licensing framework is the right structure, assigning each category the instrument that fits its governance requirement.

The hardest question is standards integrity. Implementation should be free. Modification of the standard itself should require CDCF authorization. The OASIS model, which grants implementation rights while reserving modification rights to the standards body, is the closest existing precedent.

This warrants its own dedicated thread. I will open one after this discussion settles, structured around Fr. John's four key questions.

---

5. One Question Before Drafting

The 1 Corinthians 3:10 passage in the manifesto, "like a wise master builder I laid a foundation, and another is building upon it," is the clearest scriptural grounding for the builder identity. Is that the passage you want anchoring the revised vetting criteria preamble, or is there a different passage from the manifesto you would prefer? The answer determines the opening line of the PR.

---

Mark Julius Banasihan
TAC, AI Governance, Catholic Digital Commons Foundation
May 2026

[JohnRDOrazio]

Thanks for this, @mj3b — the manifesto-anchored language replacements ("formation pathway," "commons-ready," "formation milestone") and the builder case study idea for the fragmentation memo are both strong moves.

Alignment note for future readers and for whoever drafts the PR: this comment was written against the document layout that existed before PR #9 (merged 2026-04-19), which unified AI governance into the general project governance framework. A few of the file references in §1 and §3 no longer exist on main:

Path in your comment	Current location
ai-vetting-criteria.md	Merged into project-governance/project-vetting-criteria.md as "AI domain extension" subsections within each criterion
fragmented-catholic-ai-governance.md	Moved to research/fragmented-catholic-digital-governance.md (broadened from AI-only to all Catholic digital governance — Liturgy, Scripture, Magisterial documents, Canon Law, canonical structures — with AI preserved as a detailed case study)
ai-governance/governance-as-code-catholic-ai.md	Moved to research/governance-as-code-catholic-technology.md (broadened similarly)

In practical terms this affects three rows of the §3 "Specific Changes by File" table and the §1 confirmed-gaps table. The substance carries over cleanly:

• The proposed move of "An Invitation to Iterate" into Purpose and Rationale, and the accompanier-role paragraph, now land inside the AI domain extension subsections of project-governance/project-vetting-criteria.md rather than a separate AI vetting document. (The general criteria of that same file may also want a parallel framing pass, since PR Unify Project Governance and AI Governance into single framework #9 unified the two.)
• The builder case study addition lands in research/fragmented-catholic-digital-governance.md. Since the memo is now broader than AI, the case study could either stay AI-focused (extending the existing AI case study) or be generalized — your call when drafting.
• The governance-as-code formation-tool section lands in research/governance-as-code-catholic-technology.md, which is now framed around Catholic technology generally rather than AI specifically.

Nothing in §2 (manifesto language anchor), §4 (licensing framework), or §5 (1 Cor 3:10 question) is affected. The discussion body itself (#17) has been updated to reflect the new paths; I didn't want to edit your comment without your input. Whichever you prefer — refresh the §1/§3 tables yourself, or let this reply stand as the alignment note — works.

[mj3b]

Fr. John, thank you for the path alignment note. Agreed that your reply should stand as the record rather than editing the original comment. The substance carries cleanly to the new locations.

For the benefit of future readers following this thread as an audit trail, the PR that implements these changes will touch the following current file paths:

Change	Current file
Accompanier-role paragraph and "Invitation to Iterate" framing move	project-governance/project-vetting-criteria.md (AI domain extension subsections)
Builder case study addition	research/fragmented-catholic-digital-governance.md
Governance-as-code formation-tool section	research/governance-as-code-catholic-technology.md
Language replacements (formation pathway, commons-ready, formation milestone)	README.md and project-governance/lifecycle.md
Builder Support description at each lifecycle stage	project-governance/lifecycle.md

On the builder case study scope: given that the fragmentation problem is most consequential in the AI domain and the existing memo already has detailed AI case studies, I would keep the new builder case study AI-focused. It extends the existing argument rather than generalizing it, and it stays in the lane where the governance stakes are highest.

One outstanding question from §5: is 1 Corinthians 3:10 the passage you want anchoring the revised vetting criteria preamble, or is there a different passage from the manifesto you would prefer? That determines the opening line of the PR.

Mark Julius Banasihan
TAC, AI Governance, Catholic Digital Commons Foundation