Skip to main content
Joy Repair
← Back to the report

Appendix 3 · Public Sections

Funding Charter & Philanthropic Firewall Covenant

Mapleton Fall Creek Neighborhood Data System — Principles for Maintaining Community Sovereignty While Accepting Philanthropic Capital

Preamble

Mapleton Fall Creek seeks philanthropic capital (an anticipated $1.2M anchor grant) to fund infrastructure (underground data center) and operations (continuous neighborhood census, Pro Se democracy platform). This Funding Charter establishes non-negotiable principles to ensure that accepting philanthropic capital does NOT compromise community ownership, resident authorship, data sovereignty, or democratic governance.

Philanthropic institutions operate under an invisible logic: funders believe they have the right to impose reporting requirements, define success metrics, demand data access, and direct the work toward funder-defined outcomes. This is extraction dressed as partnership.

Mapleton Fall Creek rejects this logic. We accept capital, but we retain authority.

I. Foundational Principles

Principle 1: Resident Sovereignty Is Non-Negotiable

  • The Governance Board has fiduciary duty to residents, not to funders.
  • All decisions about data collection, analysis, use, and governance are made by residents, not by funder directives.
  • Residents retain the absolute right to refuse funder conditions, return the capital, and operate independently at smaller scale.

Principle 2: Data Belongs to Residents

  • All data collected from residents is resident property, held in trust by the Community Data Trust.
  • Funders have NO rights to resident data, disaggregated records, or identifiable census information.
  • Aggregate, anonymized insights may be published. Raw resident data is never disclosed to funders or external parties without explicit resident consent.

Principle 3: Funder Metrics Are Subordinate to Resident-Defined Success

  • Mapleton Fall Creek rejects funder-imposed "logic models," "key performance indicators," and "evidence of impact" frameworks.
  • Instead, residents define what success means. Residents vote on success metrics annually.
  • Funders receive a report on resident-defined success metrics, not funder-imposed ones.

Principle 4: Resident Authorship Is Protected

  • The primary goal of this work is to enable residents to author their own future, not to generate data products for funder use, publication, or reputation.
  • Residents are not "beneficiaries" to be served or measured. Residents are authors.
  • All work is designed to increase resident voice, choice, and control—not to extract insights for external benefit.

Principle 5: Funder Accountability to Residents

  • Just as residents are accountable to the neighborhood, funders are accountable to residents.
  • Residents have the right to audit funder compliance with the Funding Charter, demand changes, and refuse future funding if funder violates commitments.

II. Core Firewall Clauses

These clauses are NON-NEGOTIABLE and must be included in every grant agreement, partnership MOU, or funding covenant. Each block below is the text to insert into the grant agreement.

Firewall Clause 1: Data Sovereignty & Non-Disclosure

The Funder acknowledges that all data collected from residents is resident property, held in trust by Mapleton Fall Creek Community Data Trust. The Funder has NO rights to resident data, disaggregated records, or identifiable census information. MFC may publish AGGREGATE, ANONYMIZED insights (e.g., "X% of residents report housing instability"). Such aggregate data does not require Funder approval for publication but must comply with the Data Firewall Trust Charter (resident privacy protected). MFC will NOT provide Funder with: individual resident records or identifiable data; census data disaggregated by neighborhood block, street, or address; health information, financial information, immigration status, or any Tier 1 sensitive data; access to raw AI model outputs before resident review and approval; integration of resident data with external databases (municipal, corporate, federal) without explicit resident vote. If Funder requests resident data for evaluation, research, or any other purpose, the request must: (1) be made in writing to the Community Data Trust (not the Governance Board); (2) specify exactly which data elements are requested, for what purpose, with what timeline; (3) be subject to explicit resident vote (2/3 majority) before approval; (4) include a confidentiality agreement subordinate to the Data Firewall Trust Charter. Unauthorized funder requests for resident data are grounds for immediate grant termination and reimbursement of funds.

Firewall Clause 2: Resident Sovereignty & Non-Interference in Governance

The Funder acknowledges that Mapleton Fall Creek governance is vested solely in the resident Governance Board, elected by residents, and accountable to residents. The Funder will NOT: demand changes to board composition, structure, or term limits; require board members to attend Funder events, training, or convenings; impose funder-defined governance "best practices" or "performance frameworks"; withhold funding due to disagreement with resident-made governance decisions; request veto power or approval rights over board decisions; place Funder representatives on the Governance Board or advisory committees. The Funder MAY: request information about board structure and decision-making processes (transparency); offer training or resources if residents request it (not imposed); participate in community events as a partner, not as a funder with leverage. Any attempt by Funder to influence board composition or governance decisions is grounds for immediate grant termination.

Firewall Clause 3: Resident-Defined Success Metrics

Mapleton Fall Creek rejects funder-imposed "logic models," "theories of change," and "key performance indicators" (KPIs). Instead, residents define success metrics annually via a public resident assembly. Residents vote on: What questions should the data center help us answer? What decisions will we make with neighborhood data? What outcomes do we want to see in our neighborhood in 1 year, 3 years, 5 years? Success metrics are resident-defined and resident-voted. Examples — Resident-Defined Metric: "By Year 1, residents will have voted on 2 major neighborhood decisions (e.g., affordable housing expansion, water management) based on neighborhood census data." Funder-Imposed (UNACCEPTABLE) Metric: "By Year 1, 60% of residents will have attended at least one community meeting." MFC reports annually on resident-defined metrics. If Funder imposes external metrics, MFC disregards them. Funder reporting focuses on: How were residents engaged in defining success? What decisions did residents make based on neighborhood data? Did those decisions produce outcomes residents desired? Where did the system fail residents? What will we do differently? Resident-defined metrics are published publicly. Funder receives the same report as the public. No separate "grant compliance report."

Firewall Clause 4: Resident Consent for Data Use & Research

Mapleton Fall Creek will NOT participate in any external research, evaluation, or publication of resident data without explicit resident informed consent. If Funder or a Funder partner requests to conduct research using resident data or insights, the protocol is: (1) Community Data Trust is notified in writing (not Governance Board); (2) research proposal is disclosed publicly to residents in plain language; (3) residents vote on participation (simple majority required); (4) if residents approve, a "Research Ethics Agreement" is signed specifying exactly which data elements will be used, what research question is being answered, how findings will be published and who retains publication rights, how residents will benefit or be harmed by the research, and whether residents will be acknowledged as co-authors or co-researchers. Publication of any findings from resident data requires: resident co-authorship (residents are not "subjects," they are researchers); resident review of publication before external circulation; attribution to residents and neighborhood (not buried in acknowledgments). Residents retain the right to refuse publication or demand changes if findings misrepresent resident experience.

Firewall Clause 5: Sunset Review & Exit Rights

This is a 5-year grant with a mandatory Sunset Review in Year 3. YEAR 1-2: Full grant performance. YEAR 3: Sunset Review. Joint assessment: Is the partnership aligned? Are residents satisfied? Is Funder honoring firewall clauses? Mutual approval required to continue past Year 3. If either party is unsatisfied, grant terms are renegotiated or terminated. YEAR 4-5: If Sunset Review approves continuation, funding resumes with potentially adjusted terms (by mutual consent). AFTER YEAR 5: Grant terminates. MFC becomes independent. If Funder wishes to continue support, it must be re-proposed and re-approved by residents. Post-Year-5 funding is a donation (not a grant with strings), or a new grant agreement with updated firewall clauses. EXIT RIGHTS: At any point, if Funder violates Firewall Clauses 1-4, MFC has the unilateral right to terminate the grant and return remaining funds. If MFC experiences operational crisis (e.g., severe economic hardship), MFC can request grant modification or early termination without penalty. Either party can exit with 90 days' notice and good-faith attempt to resolve disputes.

Firewall Clause 6: Resident Consent for Grant Acceptance

Before Mapleton Fall Creek accepts this grant, the Governance Board must hold a public resident assembly at which residents vote on the question: "Should we accept $1.2M from [Funder] under the following Firewall Clauses [list all firewall clauses above]?" A simple majority of voting residents (50%+1) is required for acceptance. If residents vote no, the grant is declined (even if it means a smaller operation). If residents vote yes, they are collectively accountable for the decision and any funder relationship that results. Residents cannot later claim they were coerced or that the Governance Board acted without consent. This resident vote is legally binding on both MFC and the Funder.

III. Funding Restrictions (What Funder Money Can & Cannot Fund)

Section 3.1: Approved Funder Uses

The Funder (or other funders) may fund:

  1. Infrastructure capital: Underground data center construction, earth tubes, thermal systems, waterproofing.
  2. Hardware costs: GPU nodes, servers, storage, networking equipment.
  3. Initial operations (Year 1-2): Data Steward salary, listening circulators, Governance Board support, community engagement.
  4. Training & capacity-building: Resident training on how to use the data system; civic skills workshops.
  5. Evaluation & learning: Independent, resident-approved evaluation (not funder-controlled).

Section 3.2: PROHIBITED Funder Uses

Funder money will NOT be used for:

  1. Trustee salary or legal defense fund (see Data Firewall Trust Charter, Section 5.2). The Trustee is funded independently by the neighborhood.
  2. Corporate cloud services or vendor lock-in (AWS, Azure, Google Cloud). All computing is local and sovereign.
  3. External research or publication without resident consent and co-authorship.
  4. Funder staff time or administration (Funder manages the grant on its own budget, not MFC's).
  5. Data brokers or corporate partnerships that extract resident data for commercial use.
  6. Compliance or reporting infrastructure (e.g., data analytics firms hired to evaluate MFC's work). If MFC needs evaluation, residents choose the evaluator.

IV. Accountability & Monitoring

Section 4.1: Mutual Accountability

  • MFC to Funder: Quarterly operational reports (infrastructure status, budget, milestones).
  • Funder to MFC: Public transparency on why funder is investing, what funder expects to learn, how funder measures success in its own institutional context (this level of transparency is rare but necessary).

Section 4.2: Resident Audit Rights

  • Residents have the unilateral right to audit funder compliance with Firewall Clauses.
  • A "Funder Accountability Report" is published annually by the Community Data Trust: Did the Funder honor data sovereignty? Did the Funder attempt to interfere in governance? Did the Funder impose external metrics? What did the Funder do well? Where did it fall short?
  • Residents can demand changes or funder exit based on this audit.

Section 4.3: Conflict Resolution

If MFC and Funder disagree on grant terms, the protocol is:

  1. Direct Negotiation (30 days): MFC and Funder attempt to resolve directly.
  2. Mediation (30 days): A neutral mediator (chosen by both parties) facilitates discussion.
  3. Resident Vote (if mediation fails): Residents vote on the disputed issue. Resident vote is binding on both MFC and Funder (or Funder relationship is terminated).

VI. Integration with Governance Documents

Section V (funder messaging and negotiation strategy) is an internal leadership document and is not published.

Section 6.1: Relationship to Bylaws & Trust Charter

The Funding Charter is subordinate to:

  1. Mapleton Fall Creek Community Association Bylaws (resident governance, not funder governance).
  2. Data Firewall Trust Charter (resident data ownership, not funder access).

In any conflict between the Funding Charter and external grant agreements, the Funding Charter prevails.

Section 6.2: Resident Vote Required Before Signature

No grant agreement is signed by the Governance Board until:

  1. The complete grant agreement (including firewall clauses) is made public.
  2. Residents vote on acceptance (simple majority required).
  3. The Trustee (not the Governance Board) verifies that all firewall clauses are included and legally binding.

VII. Template Grant Agreement Amendment

When submitting a grant proposal, include this language in the grant agreement section:

AMENDMENT TO GRANT AGREEMENT — Firewall Clauses for Community Data Sovereignty Article 1: Data Ownership & Non-Disclosure [Insert Firewall Clause 1] Article 2: Governance Autonomy [Insert Firewall Clause 2] Article 3: Resident-Defined Success [Insert Firewall Clause 3] Article 4: Research Ethics & Consent [Insert Firewall Clause 4] Article 5: Sunset Review & Exit Rights [Insert Firewall Clause 5] Article 6: Resident Consent for Grant Acceptance [Insert Firewall Clause 6] Article 7: Allowed & Prohibited Uses [Insert Section III]