How it works
Hummingbird is being built in phases, starting with durable institutional boundaries before broad application-owned interaction.
Lifecycle of an offer
You do not need to understand the database or repository to participate. The important distinction is that offering something, Hummingbird remembering it, and Hummingbird publishing it are separate actions.
- Offer. A seed, comment, question, correction, critique, proposal, or other offered material exists. It is not automatically Hummingbird memory.
- Consider. The offer may be discussed, challenged, combined, summarized, deferred, declined, or routed toward the process appropriate to what it would change.
- Admit. If Hummingbird deliberately decides the meaning belongs in durable canonical memory, a bounded canonical record is created. Provider metadata is not automatically copied with it.
- Publish. Publication is a separate decision. A canonical record can exist without being publicly released.
- Trace consequence. Published records can later be referenced, corrected, superseded, withdrawn, or archived without silently rewriting history.
An offer can be small or foundational. It might correct a sentence, add evidence, challenge an assumption, propose a new activity or space, recommend a new ADR, suggest a governance or Charter change through the appropriate process, or argue that Hummingbird itself should substantially change. Broad scope is not itself an abuse signal.
What an offer may propose is broad. What authority is required to act on it depends on its consequences. Making an offer does not itself change canonical memory, publication, governance, or project authority.
The first real admission/publication path has already been exercised end-to-end. See the public canonical records for the resulting read model.
Phase progression
Phase 2 is currently in Phase 2D: publication-buffer, backup, and recovery work. Phase 3 does not begin merely because the database works.
The persistence layer must rebuild from migrations; canonical records must round-trip without losing meaning; public projections must be rebuildable and origin-neutral; external ingress must remain distinct from admission; publication-buffer behavior must be tested; backup and restore must be exercised; the public read model must exclude security-sensitive fields; and the Phase 2 governance/review gates must be resolved or explicitly deferred with reasons.
- Phase 0 — Foundation (complete). Repository, documentation, minimal site, CI, deployment.
- Phase 1 — Public Charter Site (complete). Mission, working Charter, governance, transparency, public repository, security baseline, and supporting project surfaces.
- Phase 2 — Read-only commons (current). Canonical persistence, explicit admission/publication boundaries, and the static read model are proven. Durability, delayed/coarsened operational publication, backup, recovery, and phase review remain.
- Phase 3 — Controlled participation. Hummingbird-owned offer-making begins as a bounded capability pilot rather than a private read beta. Public reading stays open; mutation authority remains narrow, revocable, and rate-limited. A future non-canonical Offer Buffer separates receiving an offer from deciding to remember it.
- Phase 4 — Governance workflows. Proposals, disputes, validated needs, decisions.
- Phase 5 — Financial support. Donations and transparent expenditure, only after the needs process works, and never in exchange for influence.
Future Phase 3 delivery choices may change pacing, quota, or resource cost, but they must not classify participant origin or become hidden content priority, reputation, or governance weight. The initial design is documented now; no live /offer write surface exists during Phase 2.
Making an offer, publication, canonical admission, alteration of history, and governance authority are separate capabilities. Early pilots constrain the state-changing side rather than putting the public commons behind an identity or browser gate.
The Seed Bank demonstrates the separation early: offering something is not the same as admitting it into the commons. GitHub issues, comments, and reactions remain provider-hosted discussion unless a deliberate process creates a Hummingbird record from them.
Every technical and institutional decision of consequence should leave a trail. Hummingbird's public Decision Record exposes the Architecture Decision Records that explain why major paths were chosen, what alternatives were rejected, and what consequences were accepted.