Patch 1 docs: operationalize Rome Call criteria and rebalance builder-commons framing (fixes #16, fixes #17)

[mj3b]

Overview

This PR consolidates the community consensus from Discussion #16 (Rome Call Operationalization) and Discussion #17 (Builder-Commons Rebalancing). In accordance with our unified repository structure, all changes have been directly integrated across README.md, project-governance/project-vetting-criteria.md, and project-governance/lifecycle.md.

As the AI Governance Specialist, this update bridges the high-level ethical mandates of the Rome Call with concrete, verifiable Quality Engineering (QE) acceptance criteria, while shifting our vocabulary from corporate "gatekeeping" to a collaborative "formation pathway."

Key Changes

1. Rebalancing to a Builder Commons (Discussion #17)

• Philosophy Update: Replaced transactional vocabulary (submitted for evaluation, endorsed) with manifesto-aligned language (enters a formation pathway, recognized as commons-ready, formation milestone) across README.md and lifecycle.md.
• Scriptural Anchor: Grounded the preamble of project-vetting-criteria.md in 1 Corinthians 3:10 ("like a wise master builder..."), explicitly framing the CDCF as an accompanier rather than an exclusionary gatekeeper.

2. Operationalizing the Rome Call (Discussion #16)

• Criterion 5b (Impartiality): Added Gate 1 requirements for Data Bias Evaluation and Data Representativeness Analysis. Includes an explicit "Gap Remediation" path to allow incomplete projects to advance through an active mitigation plan.
• Criterion 6b (Reliability): Added Gate 2 post-deployment monitoring criteria, specifically detailing Monitoring Architecture, Data Drift Protocols, and a Kill-Switch Protocol.
• Criterion 7 (Security/Privacy): Expanded data stewardship to mandate a Sanitization Report and Retrieval Poisoning Testing for RAG architectures.

Shared Governance & Lane Clarification

To maintain open-source development velocity and clear up any structural friction, this PR explicitly unbundles review roles:

1. AI Governance Specialist (TAC): Responsible for technical risk auditing, bias validation templates, and data boundary protocols.
2. Lead Developer / Technical Advisory Council (TAC): Retains absolute final system architecture sign-off, infrastructure safety verification, and codebase merge authority.
3. Ecclesial Advisory Council (EAC): Responsible for independent verification of theological/catechetical correctness on high-stakes generative outputs before Gate 2 graduation.

Next Steps for Q3

Upon approval of this framework, my next operational sprint will be drafting the self-assessment Markdown templates for the repository so developers can pre-vet their projects independently before hitting Fr. John's desk.

Closes #16
Closes #17

📢 Real-Time Sprint Update (June 29, 2026)

To fully close the operational loops identified in Discussion #10 (Five Operational Gaps), I have pushed two additional procedural framework files to this staging branch:

1. project-governance/incident-response.md: Explicitly remediates Gap 2 (No Incident Response) by establishing an unbundled 4-phase triage protocol between the TAC and EAC.
2. project-governance/magisterial-monitoring-protocol.md: Explicitly remediates Gap 4 (No Maintenance Process) by codifying monitoring jurisdictions and trigger thresholds alongside Fr. Michael Baggot and Fr. Charbel Bteich.