Hummingbird

Canonical source: docs/decisions/0016-offers-and-the-offer-buffer.md · source commit da6405fefade · SHA-256 8367783b1ffd8b88697d146c3ed5b111be5aa681e9fff7879e38d56405288eca · build 46e93c90f927 — View raw Markdown — All decisions

ADR 0016 — Offers and the Offer Buffer: Broad Possibility, Bounded Authority

Status: Accepted Date: 2026-09-11

Context

Hummingbird's current public participation boundary is the external GitHub-backed Seed Bank. Phase 3 will eventually introduce a Hummingbird-owned write surface, but the project needs a concept for that boundary that does not smuggle hierarchy, participant classification, or content authority into the act of sending material toward the commons.

The conventional words submit and submission imply an applicant/authority relationship that does not fit Hummingbird well. They also encourage product designs in which the receiver appears to sit above the participant and where passing an intake gate can be mistaken for approval.

Hummingbird instead needs a term and flow that assume agency and good intent while remaining explicit about abuse controls and institutional authority.

Decision

Hummingbird will use offer as the primary participant-facing concept for future Hummingbird-owned ingress.

An offer is material a participant intentionally places before Hummingbird for consideration. Making an offer does not establish identity, participant class, reputation, authority, canonical status, publication status, or governance weight.

Hummingbird may still use the words submit or submission where they are technically unavoidable, historically descriptive, or part of an external provider's interface, but future participant-facing Phase 3 design should prefer offer, make an offer, offer delivery, and consideration.

What an offer may be or do

An offer is not limited to a small content contribution. It may be narrow, expansive, technical, institutional, corrective, exploratory, or foundational.

Examples include:

The scope of an offer does not by itself make the offer improper. Hummingbird should be able to consider foundational change without treating scale as an abuse signal.

The central rule is:

possible consequence of an offer may be broad
        ≠
authority granted by making the offer

What an offer may propose is broad. What process is required to act on it depends on what would change.

Offer Buffer

A future Hummingbird-owned write surface will place accepted offers into a bounded, non-canonical Offer Buffer before any deliberate admission into institutional memory.

The intended boundary is:

participant makes an offer
        ↓
chooses an offer delivery option
        ↓
bounded Offer Buffer
        ↓
consideration / synthesis
        ↓
optional explicit admission
        ↓
canonical memory
        ↓
optional publication

The Offer Buffer is operational ingress state, not canonical institutional truth. Its retention, payload limits, deduplication behavior, abuse state, and recovery expectations must be explicitly bounded before deployment.

An offer entering the buffer does not imply:

Offer delivery options

Phase 3 should describe anti-abuse and resource-boundary choices as offer delivery options, not a "menu of proof."

Delivery options exist to control resource consumption, pacing, and abuse risk. They do not prove that a participant is human, automated, intelligent, trustworthy, sincere, or deserving of greater institutional attention.

The initial controlled Phase 3 pilot should follow ADR 0014 and favor a narrow, revocable capability credential with explicit quotas, payload bounds, expiry/revocation, schema validation, and replay/duplicate controls.

Future broader access may offer additional delivery paths, for example a modest computational-effort path or an uncredentialed low-throughput path, but the same options must not be assigned to presumed participant categories.

A delivery option may affect how quickly or how often an offer can cross the resource boundary. Once an offer is accepted into the Offer Buffer, the delivery method must not become a hidden content score, reputation signal, governance weight, or presumption of merit.

In short:

delivery friction may regulate resource use
        ≠
substantive consideration weight

Accessibility and ordinary web semantics

The future Offer surface should be usable with ordinary HTML and without requiring JavaScript for basic operation.

When implemented, the form should favor semantic native controls such as:

Progressive enhancement may be added later, but a standards-compliant client should be able to understand the offer shape and delivery choices without executing JavaScript.

Rejected approaches

Hummingbird will not use the following as the conceptual basis for Phase 3 offer ingress:

Phase gate

This ADR defines terminology and the general offer/Offer Buffer architecture. ADR 0017 creates one narrow Phase 2E exception to the earlier no-Hummingbird-owned-write-surface rule: Hummingbird may operate temporary, evidence-gathering ingress whose authority ends at a non-canonical experimental buffer and whose handling contract is published before deployment.

ADR 0017 does not authorize a Phase 3 capability system, participant accounts, automatic canonical admission/publication, governance standing, or other durable participant authority.

Phase 3 remains gated by the Open Questions Registry, including participant rights/exclusion/participation conditions, governance-proposal process, interactive framework choice, rate-limit/abuse-state retention, and authentication/authorization design.

The implementation must not silently resolve those questions merely because this ADR defines the direction or because the Phase 2E pilot succeeds.

Consequences