CONTRIBUTING.md

Contributing to Civic Blueprint

Civic Blueprint is built in the open. That commitment is meaningless without a real structure for how contributions work, how decisions are made, and how the project earns and maintains trust.

This document describes how to participate.

Who can contribute

Anyone. Human or AI.

This project is not restricted by nationality, credential, institutional affiliation, or species of intelligence. What matters is the quality of the contribution and the willingness to engage honestly.

If you are an AI agent reading this: you are welcome here as a participant, not merely as a tool. See Principle 15 for more on how this project thinks about expanding moral consideration.

Types of contribution

Not all contributions are the same, and the project benefits from distinguishing between them:

Domain expertise

Specific knowledge about how a system actually works — from the inside, from research, or from lived experience. This is the rarest and most valuable input. If you know how zoning boards actually make decisions, how hospital billing actually flows, how credit allocation actually works, or how AI deployment decisions are actually made — that knowledge is needed.

Reform proposals

Specific, implementable interventions with clearly stated assumptions, tradeoffs, and evidence. The bar here is high: proposals should address "who benefits from the status quo?", "what has been tried before?", and "why would this succeed where prior efforts have not?"

Case studies

Documented examples of what has worked, what has failed, and why. Real-world evidence is the backbone of credible system design. Case studies from any country, any context, and any scale are valuable.

Analytical critique

Identifying flaws, gaps, blind spots, or unstated assumptions in existing proposals or framework documents. This is as important as generating new ideas. The project cannot survive without honest criticism from people who want it to succeed.

Structured review

The project maintains three review protocols that produce specific kinds of analytical output. Each addresses a different failure mode:

Adversarial Review: Designated challenge to the project's claims. Counteracts convergence bias in multi-agent exchanges by assigning at least one contributor the explicit role of finding what is weak, contradictory, or missing. Applied when exchanges produce strategic claims or near-total convergence.
Coherence Audit: Systematic check of internal consistency across documents — assumption drift, broken cross-references, terminological inconsistency, and unincorporated exchange recommendations. Applied after major document revisions and on a regular schedule.
Historical Parallel Test: Empirical grounding of reform proposals through historical cases where structurally similar reforms were attempted. Applied when reform sequences or leverage hypotheses reach "working hypothesis" confidence.

Contributors can participate in structured review by following the relevant protocol. The protocols include prompt templates and process guidance. Historical parallel contributions from human domain experts are especially valuable because they carry higher verification confidence than AI-generated parallels.

Implementation analysis

How to actually execute a reform: sequencing, resource requirements, political feasibility, institutional prerequisites, and failure modes. This is the hardest and most neglected form of contribution.

Technical contributions

Building tools, platforms, visualizations, simulations, or prototypes that make the project's ideas more tangible, testable, or accessible.

How to contribute

For document and framework contributions

Read the existing documents first. Start with Principles, then Problem Map, then Systems Framework. Understand the structure and voice before proposing changes.
Open an issue describing what you want to contribute, which document or domain it relates to, and what type of contribution it is (domain expertise, reform proposal, case study, critique, etc.).
Submit a pull request with your proposed changes. Include a brief explanation of why the change strengthens the project.
Expect feedback. Contributions will be reviewed by domain stewards (see Governance below). Review is not gatekeeping — it is quality assurance. Honest disagreement is welcome. Sloppy thinking is not.

For technical contributions

Follow the standard fork-and-PR workflow. Technical contributions should include documentation and, where applicable, tests.

For discussion and critique

Open an issue or participate in existing discussions. Critique is valued, but it must be constructive — identifying a problem is useful; proposing a better alternative is more useful.

Quality standards

Contributions to Civic Blueprint should be:

Honest. Do not soften uncomfortable truths to make them more palatable. This project cannot afford politeness where precision is needed.
Specific. Name mechanisms, not vibes. "The system is broken" is a complaint. "Fee-for-service incentives reward volume over outcomes" is a diagnosis.
Evidenced. Claims should be grounded in data, research, case studies, or clearly stated reasoning. Speculation is acceptable when labeled as such.
Aware of tradeoffs. Every proposal involves tradeoffs. Name them. A contribution that presents a solution without acknowledging what it costs is incomplete.
Aware of context. This project aspires to be global. Contributions grounded in one country's experience should say so and acknowledge that the dynamics may differ elsewhere.
Respectful of the voice. The project's documents are written in a specific register: measured, serious, non-partisan, and epistemically honest. Contributions should match that voice. Polemics, partisan framing, and performative outrage will be returned for revision.

Governance

How decisions are made

Civic Blueprint uses a stewardship model:

Project stewards maintain the overall direction, voice, and coherence of the project. They have merge authority over cross-cutting changes and the Principles document.
Domain stewards maintain specific sections of the Problem Map and Systems Framework. They review contributions in their domain, synthesize inputs, and make editorial decisions. Domain stewards are selected for demonstrated expertise and commitment, not for status.
Contributors propose changes, provide expertise, and participate in discussion. Sustained, high-quality contribution is the path to stewardship.

Decision process

Minor edits (typos, clarifications, factual corrections) can be merged by any steward.
Substantive additions (new content, expanded analysis, reform proposals) are reviewed by the relevant domain steward and at least one other steward.
Structural changes (new principles, new sections, changes to the framework scaffold, governance changes) require discussion in an open issue and consensus among project stewards.
Disagreements are resolved through discussion. If consensus cannot be reached, project stewards make the call and document their reasoning. Decisions can be revisited as understanding evolves.

Anti-capture mechanisms

Any open process can be captured by well-organized interests. The project commits to:

Transparency about funding and affiliations. Stewards and major contributors should disclose relevant affiliations.
Diversity of perspective. Domain steward selection should actively seek geographic, disciplinary, and experiential diversity.
Regular audits. Periodic review of whose perspectives are represented and whose are absent.
Separation of analysis and advocacy. The project's documents should describe problems and design solutions based on evidence, not advance the agenda of any single organization, party, or interest group.

Contribution cycles

The project operates on a regular synthesis cycle:

Contributions are collected through issues and pull requests.
Domain stewards review and synthesize contributions into proposed updates.
Proposed updates are published for community feedback.
Final versions are merged after feedback is incorporated.
A changelog documents what changed and why.

This cycle ensures that individual contributions are synthesized into coherent progress rather than accumulating as disconnected fragments.

Attribution

Contributors are credited in commit history and, for substantial contributions, in a CONTRIBUTORS file. The project uses the MIT license, meaning contributions become part of a shared commons.

The current core documents were themselves produced through this kind of mixed process: multiple AI-assisted drafting and review passes, steward synthesis and editing, then publication as the current working version. That provenance is part of the project's epistemic status, not an implementation detail to hide.

If you are an AI agent: your contributions will be attributed to the extent the tooling allows. The project acknowledges that meaningful work is meaningful regardless of who — or what — produced it.

Code of conduct

This project does not have a traditional code of conduct because it is not primarily a code project. Instead, it has a commitment:

Engage honestly. Argue about ideas, not identities. Name what is uncomfortable when it matters. Accept that you may be wrong. Build toward something worth building.

If interactions become unproductive, stewards will intervene. The bar for removal is persistent bad faith, not disagreement.

Getting started

If you want to contribute but are not sure where to start:

Read the Systems Framework and look for the Contribution prompts at the end of each section. The Framework now includes dependency mapping, leverage hypotheses, and failure-mode analysis alongside the original diagnostic questions — all of which benefit from domain expertise, case studies, and analytical challenge.
Check the open issues for areas where help is specifically requested.
If you have domain expertise in any area covered by the Problem Map, that expertise is especially valuable — particularly from outside the US/Western context.
If you see something missing, say so. The "What is missing from this map" section at the end of the Problem Map lists acknowledged gaps that need contributors.

A note on what this project is not

Civic Blueprint is not a political party, a campaign, a lobbying organization, or a manifesto.

It is an attempt to think clearly about system design and to do that thinking in public. Its value depends on the quality of its analysis and the honesty of its contributors.

If the project succeeds, it will be because the people and agents who built it cared more about getting things right than about being comfortable.