Add open-source requirement to AI vetting criteria

[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.

---

Context

An audit of all repo documents against the CDCF bylaws and manifesto found that the AI vetting criteria contain no open-source licensing requirement.

Problem

Bylaws purpose 1 specifically refers to "open-source software," and the manifesto describes the CDCF as a commons for "open-source digital tools." The AI domain extension subsections of project-governance/project-vetting-criteria.md (formerly ai-governance/ai-vetting-criteria.md) never mention open-source licensing as a requirement or consideration for incubation or graduation. A tool could theoretically pass all eight criteria while being entirely proprietary.

This is a significant omission given that open-source is foundational to both the bylaws and the manifesto's commons model.

Suggested approach

Add an explicit open-source licensing requirement (or criterion) to the vetting criteria. Consider whether this should be:

• A hard gate requirement (must be open-source to enter incubation)
• A graduation requirement (must be open-source to graduate)
• A weighted criterion with exceptions for proprietary tools that meet other criteria

The general project vetting criteria should also be checked for consistency on this point.

Affected files

• project-governance/project-vetting-criteria.md — both the general criteria and the AI domain extension subsections

Dependencies

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

Identified during bylaws/manifesto alignment audit.

[mj3b]

Response to Discussion #13: Open-Source Requirement in AI Vetting Criteria

Version: v1.0
Submitted by: Mark Julius Banasihan, TAC, AI Governance
In response to: Discussion #13 opened by Fr. John R. D'Orazio, April 17, 2026
Status: Ready for board and council review

---

Executive Summary

This response addresses a gap the bylaws audit correctly identified: the AI vetting criteria contain no open-source licensing requirement, despite both the bylaws and the manifesto describing CDCF in open-source terms.

The analysis below shows that a binary open-source gate would exclude widely deployed Catholic AI tools while providing no additional governance protection. The proposed alternative resolves the tension: replace the license question with an auditability and risk-tiering framework grounded in the same accountability values the open-source requirement was designed to protect.

This framework is calibrated for 2026. AI capabilities are evolving rapidly -- agentic systems, multi-modal tools, and new deployment architectures will require revisiting these criteria. A reassessment trigger is built into the framework at §11.

Three decisions require board and council input before a PR can be drafted. They are stated plainly in §8.

---

1. What the Bylaws and Manifesto Actually Say

The audit finding is accurate. The language in each document is distinct and worth quoting precisely before drawing any conclusions.

Document	Exact language	Location
Bylaws	"coordinate, develop, steward, and disseminate open-source software, data repositories, technical standards, and digital platforms in service of the Catholic Church's evangelizing mission"	Article I, Section 2, Purpose 1
Manifesto	CDCF described as a commons for "open-source digital tools" dedicated to "aggregating, vetting, and communalizing" them	Builder's Mandate section
Bylaws, AI-specific purpose	"promote the ethical development and governance of digital technologies and artificial intelligence in accordance with Catholic social teaching"	Article I, Section 2, Purpose 5

Two observations follow from this reading.

First: The bylaws' open-source language is in Purpose 1 (digital infrastructure) and does not appear in Purpose 5 (ethical AI). The bylaws do not mandate open-source AI specifically. They mandate open-source software infrastructure. The vetting criteria need to resolve the tension between the infrastructure mandate and the AI ethics purpose, not simply apply the software standard to AI tools.

Second: Neither document defines "open-source" with precision. The Open Source Initiative published its first formal Open Source AI Definition in October 2024. The bylaws and manifesto predate that definition and were written when "open-source" meant something well-understood for software but not yet settled for AI systems.

---

2. Why "Open Source" for AI Is Not the Same Standard as for Software

This distinction is the foundation of the entire analysis. A tool can be fully open-source by traditional software standards and still provide less governance accountability than a well-documented proprietary AI tool.

Component	Traditional open-source software	OSI Open Source AI Definition 1.0 (October 2024)
Source code	Required	Required
Model weights	Not applicable	Required
Training data	Not applicable	Required, or detailed provenance documentation where data cannot legally be released
Fine-tuning methodology	Not applicable	Required
Architecture documentation	Not applicable	Required

The OSI definition requires that a skilled person be able to recreate a substantially equivalent system. Most tools the Catholic community calls "open source" -- including tools built on widely used open-weight model families -- do not meet this definition. They are open-weight, not open-source. The criteria document needs to be precise about which standard applies, because the governance obligations are materially different.

A tool can declare an MIT or Apache 2.0 license and still provide no insight into its training data, its known limitations, or its demographic coverage. License type is a proxy for accountability, not accountability itself.

---

3. The Ecosystem Consequences of Each Option

Before choosing among Fr. John's three options, the board and councils should see what each does to the Catholic AI ecosystem CDCF exists to serve.

Option	What it includes	What it excludes	Governance effect
Hard gate at incubation	Open-weight tools; tools fully meeting the OSI Open Source AI Definition	All closed-source Catholic tools regardless of theological rigor or audit transparency	CDCF becomes a software commons, not a governance commons. Catholic AI tools in healthcare, catechesis, and parish operations that do not release source code are permanently ineligible.
Graduation requirement	Same inclusions; plus tools on an open-source trajectory	Same exclusions for mature tools with no open-source trajectory	Provides an incubation pathway for willing builders; still excludes tools most Catholic institutions are already using
Weighted criterion with exceptions	All Catholic AI tools that satisfy an auditability floor	Tools that refuse any form of audit access	CDCF becomes a governance commons for the whole Catholic AI ecosystem, open and closed alike

The open-source community's legitimate concern deserves direct acknowledgment. The open-source tradition -- represented within the TAC by members with deep roots in Linux, Ansible, Drupal, and Catholic open-source development -- holds that auditability, community ownership, and long-term sustainability are best protected by license, not by confidentiality agreements. That argument carries real weight. A closed-source tool under a confidentiality agreement can withdraw audit access at any time. An open-source tool cannot.

The response to that concern is not to dismiss it but to name what CDCF can actually govern. A hard open-source gate protects the commons from closed-source capture. It also places the governance burden entirely on license type rather than on the content of the audit. A tool with an Apache 2.0 license and no training data documentation satisfies the gate. A tool with a rigorous independent audit under a confidentiality agreement does not. Neither outcome serves the mission.

The right frame: minimum auditability floor, with open-source status as a positive governance signal that reduces the audit burden -- not as an exclusion criterion.

---

4. The Operative Standard: Auditability as a Licensing Model

The external governance environment has moved firmly toward auditability as the operative standard, independent of license type.

Framework	Position on open vs. proprietary
EU AI Act (high-risk rules, August 2026)	Open-source exemption does not apply to high-risk AI systems. Auditability is required regardless of license.
NIST AI RMF (March 2025 update)	Emphasizes model provenance, data integrity, and third-party assessment. Does not require open-source licensing.
DoD AI Ethics Principles (October 2020)	Equitable, traceable, reliable, governable: accountability through documentation and human oversight, not license type.
OSI Open Source AI Definition 1.0 (October 2024)	Sets a standard most tools calling themselves "open source" do not actually meet.
AIUC-1 AI Agent Standard (2026-01)	Defines governance requirements for AI agents based on capability scope and deployment risk, not license type.

Proposed operative standard for project-governance/project-vetting-criteria.md:

A project seeking CDCF commons recognition must provide an AI Bill of Materials (AIBOM) that documents training data provenance, model weights or equivalent documentation, software dependencies, deployment architecture, and known limitations.

Open-source tools: The AIBOM is public and verifiable by any reviewer. Open-source status reduces the Gate 1 audit burden.

Closed-source tools: The AIBOM is provided to CDCF under a licensing agreement granting CDCF audit rights as a condition of commons recognition. CDCF does not publish it. Commons recognition is suspended if audit access is withdrawn.

This is a licensing model, not an IP transfer model -- directly consistent with the Apache, Linux Foundation, and Eclipse approaches identified in Discussion #15. Contributors grant audit rights; CDCF does not own the tool. This framing resolves both #13 and #15 with a single mechanism.

---

5. Risk Tiering: Proportionate Governance by Use Case

Not every Catholic AI tool carries the same governance stakes. A parish scheduling assistant and an AI tool that informs clinical decisions in a Catholic hospital are not the same governance object. The vetting criteria should assign different auditability floors proportionate to consequence.

Proposed Catholic AI Risk Tiers:

Tier	Definition	Catholic deployment examples	Gate 1 AIBOM	Independent audit	Post-deployment monitoring	External framework alignment
Tier 1: Mission-critical	Direct consequence for human dignity, sacramental integrity, clinical outcomes, or vulnerable population welfare	AI pastoral care tools, sacramental record systems, Catholic healthcare clinical decision support, AI in Catholic schools affecting student placement	Full AIBOM required; public or under CDCF audit rights agreement	Required before Gate 1	Mandatory; data drift detection and reliability monitoring specified	EU AI Act high-risk; WHO AI Health Ethics Guidance; NIST AI RMF high-stakes profile
Tier 2: Mission-adjacent	Significant operational consequence; touches personal data or catechetical formation	AI catechetical content tools, parish management systems, diocesan administrative automation, donation processing	AIBOM required; summary format acceptable	Required before Gate 2; conditional at Gate 1 with defined timeline	Required; annual re-vetting cycle	EU AI Act limited risk; NIST AI RMF standard profile
Tier 3: Mission-supporting	Minimal consequence; internal productivity or communication support	Internal scheduling, communications assistance, document drafting tools for staff	Model card and training data provenance declaration	Declaration of conformity; no independent audit required	Recommended; no formal requirement	EU AI Act minimal risk; documentation only

Tier assignment process:

The TAC reviewer assigns a tier at Gate 1 submission using three diagnostic questions:

Diagnostic question	Tier 1 signal	Tier 2 signal	Tier 3 signal
Who is directly affected by the tool's outputs?	Vulnerable populations, patients, students, persons in pastoral care	Parish or diocesan staff and the communities they serve	Internal staff only
What is the consequence of a failure or doctrinal error?	Harm to human dignity, doctrinal error reaching the faithful, clinical harm, legal liability	Operational disruption, reputational damage, financial loss	Minor inconvenience
Does the tool produce autonomous outputs or operate under direct human review at every step?	Autonomous or semi-autonomous outputs with consequential effect	Human review at key decision points	Human review at every step

---

6. The AI Bill of Materials: Instrument and Requirements

An AIBOM is a structured inventory of every component that determines how an AI system was built, what it can do, and what it cannot do. It is the instrument that makes the auditability standard operational rather than aspirational.

What a CDCF-required AIBOM documents:

Component	What is documented	Why it matters for Catholic governance
Training data provenance	Sources, collection methods, known gaps, demographic coverage	Enables bias assessment; establishes whether populations Catholic institutions serve are represented
Model weights or equivalent	Weights (open tools) or architectural description and capability scope (closed tools)	Establishes what the model can and cannot do; prevents capability overstating
Software dependencies	All libraries, APIs, and third-party services the tool relies on	Identifies supply chain risks; supports maintainer abandonment assessment
Deployment architecture	How the tool is hosted, what data it transmits, where data is stored	Enables GDPR and HIPAA compliance assessment; identifies data sovereignty risks for European Catholic institutions
Known limitations	Documented failure modes, accuracy boundaries, edge cases	Provides honest capability scope; prevents over-reliance in high-stakes pastoral contexts
Version and update history	Last update date, nature of changes, approval process	Enables re-vetting trigger assessment; directly addresses Operational Gap 1 from Discussion #10
Ecclesial review record	Whether outputs have been reviewed by qualified theological reviewers	Unique to CDCF; connects the technical and canonical accountability layers

AIBOM requirements by tier:

AIBOM component	Tier 1	Tier 2	Tier 3
Training data provenance	Required in full	Required; summary acceptable	Declaration only
Model weights or equivalent	Required	Required; architectural description acceptable for closed tools	Not required
Software dependencies	Required in full	Required	Not required
Deployment architecture	Required in full	Required	Not required
Known limitations	Required in full	Required	Recommended
Version and update history	Required; defined thresholds trigger re-vetting	Required; annual review	Not required
Ecclesial review record	Required	Required for catechetical tools; recommended otherwise	Not required

---

7. The Agentic AI Dimension: A Present Gap

This section names a governance gap the discussion header did not anticipate. It belongs here because the CatholicOS org has already deployed agentic infrastructure and the current vetting criteria do not govern it.

CDCF has already deployed agentic AI infrastructure. The liturgical-calendar-mcp repository in the CatholicOS org is an MCP (Model Context Protocol) server in active development. The repository description states: "An MCP server that will allow AI agents to interact with the Liturgical Calendar API." An MCP server is not a static tool. It is an interface through which AI agents take autonomous actions.

The current vetting criteria govern static AI tools. They do not govern agentic systems -- agents that plan, act, chain tool calls, and operate across systems with reduced human oversight at each step.

Why agentic AI is categorically different from static tools:

Dimension	Static AI tool	Agentic AI system
How it operates	Responds to direct human queries	Plans and executes multi-step actions autonomously
Human oversight	At every interaction	At workflow initiation; reduced during execution
Failure mode	Incorrect output	Unauthorized action with real-world consequence
Governance question	What was it trained on and what does it output?	What can it do, to whom, under what conditions, and who can stop it?
AIBOM scope	Model and training data	Model, tools, permissions, memory architecture, human override triggers

OWASP Top 10 for Agentic Applications 2026 mapped to Catholic deployment scenarios:

Published December 2025 through collaboration with over 100 industry experts, this is the first formal taxonomy of agentic AI risks. Each risk maps directly onto the Catholic deployment context.

OWASP Agentic Risk	Definition	Catholic deployment manifestation
Goal hijacking	Attacker manipulates agent goals via injected content	A catechetical AI agent manipulated via poisoned knowledge base content produces doctrinally inaccurate responses
Tool misuse	Agent uses authorized tools for unauthorized purposes	A pastoral care agent granted access to sacramental records uses that access beyond its defined scope
Identity abuse	Low-privilege agent relays instructions to high-privilege system	A parish scheduling agent relays instructions to a diocesan records system it was never intended to reach
Memory poisoning	Agent conversation history tampered to alter behavior across sessions	An AI used in ongoing formation contexts is manipulated by altering its session memory
Cascading failures	Failure in one agent propagates across connected systems	A failure in one CDCF-integrated MCP server propagates across multiple Catholic institutions using the same commons infrastructure
Rogue agents	Agent takes autonomous actions no human authorized	An agent operating in a Catholic healthcare context begins making referral decisions no human at the institution approved

MAESTRO: Seven-layer agentic threat model

Introduced by the Cloud Security Alliance in February 2025, MAESTRO (Multi-Agent Environment, Security, Threat, Risk, and Outcome) maps risk across seven layers of an agentic system's architecture. Most Catholic AI governance conversations happen at Layer 1 and miss Layers 3 through 7, where agentic risks live.

MAESTRO Layer	What it covers	Current CDCF coverage	Gap severity
L1: Foundation model	Base model capabilities, training, alignment	Addressed by C3 and C4	Covered
L2: Data operations	Training data, retrieval pipelines, data flows	Addressed by AIBOM; strengthened by CMDDR/CLEDR adoption	Covered
L3: Agent framework	Planning, memory, tool orchestration logic	Not addressed	High
L4: Deployment infrastructure	Hosting, APIs, identity management, access controls	Partially addressed by C7	Medium
L5: Security and compliance	Cross-layer controls, audit logging, incident response	Not addressed	High
L6: Agent ecosystem	Inter-agent communication, shared resources, MCP connections	Not addressed -- directly relevant to liturgical-calendar-mcp	High
L7: Evaluation and observability	Monitoring, anomaly detection, human override triggers	Partially addressed by Reliability criterion proposed in #16	Medium

Proposed CDCF MCP Security Profile

This profile addresses a present requirement for any MCP server accepted into the CDCF commons. It is grounded in the OWASP MCP Top 10 (v0.1, 2025) and the AIUC-1 AI Agent Standard (2026-01).

Requirement	Description	OWASP MCP Top 10 alignment
Tool permission scoping	Each MCP tool must declare the minimum permissions it requires; no tool may request broader access than its documented function requires	Prevents privilege escalation and unauthorized access
Human override trigger	Any MCP tool that modifies data or triggers external actions must document conditions under which a human must approve before execution	Preserves C2 Human Accountability for agentic workflows
Session integrity	MCP server must implement session validation preventing memory poisoning and session hijacking	Addresses memory and session integrity risks
Audit logging	All tool calls, inputs, and outputs must be logged with timestamps and caller identity	Supports post-incident review and re-vetting triggers
Retrieval poisoning testing	Any MCP server serving a knowledge base must provide evidence of retrieval poisoning testing before Gate 1 acceptance	Prevents goal hijacking via knowledge base manipulation

---

8. Three Decisions Required

These three decisions require board and council input before a PR can be drafted. The TAC has provided recommendations; final authority rests with the board.

#	Decision question	Options	TAC recommendation	Council input needed
D1	Does CDCF adopt auditability-over-license as the operative standard, with open-source status reducing the audit burden rather than serving as an exclusion criterion?	(a) Hard open-source gate; (b) Graduation requirement; (c) Auditability floor with AIBOM, open-source as a positive governance signal	(c). Aligns with EU AI Act, NIST AI RMF, DoD AI Ethics Principles, and AIUC-1. Consistent with the Apache/Linux Foundation licensing model identified in #15.	Board vote required; EAC advisory input on the licensing mechanism
D2	Does CDCF adopt a three-tier risk classification for AI tools with different AIBOM requirements at each tier?	(a) Uniform requirements for all tools; (b) Three-tier framework as proposed in §5; (c) EAC defines tiers with TAC technical input	(b) as a starting framework. Tier 1 definitions carry pastoral and canonical implications that warrant EAC review.	Fr. Corwin Low, O.P. and Fr. Patrick Carter, O.S.B. are well-positioned to advise on Tier 1 boundary conditions given their backgrounds in technology, ethics, and moral theology
D3	Does CDCF adopt an Agentic AI extension and a CDCF MCP Security Profile, given that liturgical-calendar-mcp is already in active development?	(a) Defer until a more complex agentic project is submitted; (b) Adopt the MCP Security Profile now; develop the full Agentic AI extension in a dedicated discussion; (c) Develop both in parallel with this PR	(b). The MCP Security Profile addresses a present gap. The full Agentic AI extension warrants its own dedicated discussion.	TAC review sufficient for MCP Security Profile; Agentic AI extension should return to board before PR

---

9. Relationship to Other Open Discussions

Discussion	Connection to #13
#16: Rome Call traceability	The Impartiality criterion requires training data bias testing. The AIBOM training data provenance component carries that evidence. The two proposals are the same infrastructure requirement from different angles.
#17: Builder-commons reframing	The auditability floor is a formation tool. CDCF accompanies closed-source Catholic tool builders toward the AIBOM standard rather than excluding them. Discussion #17 language should frame the AIBOM requirement accordingly.
#10: Five Operational Gaps	Operational Gap 1 (no post-endorsement re-vetting trigger) is structurally resolved by the AIBOM version history requirement and the Tier 1 data drift detection obligation. Coordinate the PRs.
#15: IP transfer vs. commons ethos	The audit rights licensing agreement proposed here directly resolves the IP transfer conflict identified in #15. Contributors grant audit rights; CDCF does not own the tool. The two discussions should be resolved with a single mechanism.

---

10. Standards, AIBOM, and the Full Architecture

CDCF is building canonical data standards: CMDDR, CRMETDR, and CLEDR. Those standards are AI training data in formation. Every Catholic institution building an AI tool trained on or operating against CDCF-standardized data will need an AIBOM citing those standards as provenance.

The AIBOM requirement in the vetting criteria and the standards work are the same infrastructure project approached from two directions. Standards define what responsible Catholic data looks like. The AIBOM ensures that any tool built on that data is accountable to the community that produced it.

---

11. Forward-Looking Reassessment Trigger

This framework is calibrated for the AI deployment landscape of 2026. It should not be treated as settled.

AI capabilities are evolving faster than governance cycles. Three conditions should trigger a formal reassessment of the vetting criteria before the next scheduled review:

Trigger condition	Rationale
A CDCF-recognized agentic tool is deployed in a Tier 1 context	The MCP Security Profile and agentic extension proposed here are baseline standards. Real deployment will surface gaps the current framework did not anticipate.
A material change in the EU AI Act implementing rules or NIST AI RMF profile occurs	The Tier 1 compliance requirements are tied to August 2026 enforcement dates. Regulatory changes require criteria alignment.
An OWASP LLM Top 10 or Agentic Top 10 major version update occurs	The security baseline for AI systems is updated annually. The MCP Security Profile and AIBOM requirements should track these updates.

The TAC commits to a formal vetting criteria review no later than Q1 2027, or earlier if any trigger condition above is met. The review should include representatives from the Board, EAC, and TAC and should evaluate whether the risk tier definitions, AIBOM requirements, and agentic governance profile remain current.

---

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

---

References

Source	Publication	Key finding for this discussion
Open Source Initiative, Open Source AI Definition 1.0	October 2024	Open-source AI requires training data provenance, model weights, and architecture documentation -- a standard most tools calling themselves open-source do not meet
EU AI Act (Regulation 2024/1689)	In force August 2024; high-risk rules August 2026	Open-source exemption does not apply to high-risk AI systems; auditability required regardless of license
NIST AI RMF 1.0 and March 2025 update	January 2023 / March 2025	Emphasizes model provenance, data integrity, and third-party assessment over license type
DoD AI Ethics Principles	October 2020	Equitable, traceable, reliable, governable: accountability through documentation and human oversight
AIUC-1 AI Agent Standard	Version 2026-01	Governance requirements for AI agents based on capability scope and deployment risk, not license type
OWASP Top 10 for Agentic Applications 2026	December 2025	First formal taxonomy of agentic AI risks; directly actionable as a governance control baseline
OWASP MCP Top 10	Version v0.1, 2025	Security risk taxonomy for Model Context Protocol servers; basis for the proposed CDCF MCP Security Profile
Cloud Security Alliance, MAESTRO Framework	February 2025	Seven-layer agentic AI threat model; maps risk across the full agent architecture stack
WHO AI Health Ethics Guidance	2021/2024	International standard for AI governance in healthcare contexts; grounds Tier 1 requirements for Catholic healthcare deployments
MCP Safety Audit, Radosevich and Halloran, Leidos	2025	Demonstrates critical MCP security vulnerabilities including remote code execution and credential theft
OWASP AIBOM Project; SPDX 3.0 AI Profile	2025	Emerging standard for AI Bill of Materials documentation and component inventory

[musaabhasan]

An open-source requirement is strongest when it is framed as governance evidence rather than only a preference. I would add explicit review fields for license compatibility, source availability, build or deployment reproducibility, maintainership continuity, dependency disclosure, and data-processing transparency.

For AI-specific vetting, the open-source criterion can sit beside model or system documentation, data handling, capability boundaries, evaluation evidence, and an exit plan. That keeps the rule practical: open source is required for core infrastructure and public-interest tools, while exceptions need a documented risk acceptance, review date, and migration path.

The useful control question is: can the community independently inspect, maintain, replace, and govern the tool if the original maintainer or vendor is no longer aligned with the mission?