Foundation in formation Interim stewardship: Celiums Solutions LLC Read the status note

Participation / Conversation-gated contributions

Discuss first. Build what the project can review.

Every pull request begins with a public conversation and a maintainer-approved tracking issue. Approval establishes scope, evidence, risk, and a reviewer before implementation consumes contributor or maintainer time.

Required flow

01

Discuss

Start early ideas, architecture, research, governance, and questions in Discussions. File reproducible bugs and concrete proposals through an issue form.

02

Approve

A maintainer records scope, non-goals, acceptance criteria, risk, AI expectations, owner, reviewer, and expiry on the tracking issue.

03

Build

Only decision:approved authorizes implementation. Claim the issue, stay within scope, and keep the change small enough to understand.

04

Review

Link one primary issue, disclose provenance and AI, pass CI and DCO, and obtain the independent human approvals required by risk.

Before a PR

A Discussion is not an implementation permit.

An accepted Discussion becomes a tracking issue. A pull request is allowed only after a maintainer applies decision:approved and confirms an implementation owner and reviewer. Approval permits work; it does not promise merge.

Pull requests without an approved issue may be closed without technical review. The only exception is an authorized confidential security change using exception:private-security.

Issues hold decisions. Pull requests implement decisions.

Review capacity

External workMaximum two assigned implementation issues and two open PRs per repository.
Preferred changeUp to 200 changed lines in one logical unit.
Review plan501–1,000 changed lines require review:planned.
Large changeOver 1,000 lines or 30 files must split or receive exception:large-pr.
Normal riskOne approving human maintainer, current CI, DCO, and resolved review.
Critical riskTwo human maintainers and a 72-hour window after the latest substantive commit.

AI-assisted work

Welcome, disclosed, and owned by a human.

AI may assist with code, tests, documentation, analysis, and private review. The contributor remains responsible for every line, claim, source, test, and artifact. They must understand the subsystem, review the complete diff, verify generated analysis against authoritative evidence, and explain the solution in their own words.

Material AI use must be declared in the approval issue and pull request. It receives ai:assisted and is reviewed under the target repository's risk policy; tool use alone does not determine risk. AI cannot be an author, DCO signatory, reviewer, maintainer, or reason to merge.

Do not paste generated responses as conversation with maintainers. Do not send secrets, vulnerabilities, private source, personal data, or confidential artifacts to an unauthorized provider. Do not accuse contributors based on writing style.

Read the AI policy

Ways to contribute

01 / Build

Code and tests

Implement an approved issue, preserve project invariants, and prove success and failure behavior.

Browse Hyphae issues
02 / Reproduce

Evidence

Run a documented protocol on another environment. Null results and regressions belong in the record.

Review methods
03 / Explain

Documentation

Clarify boundaries, operations, security assumptions, accessibility, translations, diagrams, or examples.

04 / Review

Threats and contracts

Review is a contribution. Examine parsers, persistence, release integrity, public contracts, rights, and ambiguity.

Review standard
05 / Govern

Institution design

Improve project charters, role progression, transparent decisions, continuity, and accessible participation.

Governance record
06 / Maintain

Earn responsibility

Sustained work and sound judgment across code, review, research, operations, and community can lead to explicit authority.

Current roles

Terms and safety

Inbound and outbound terms match.

Software and implementable normative specifications use Apache-2.0. Narrative documentation uses CC BY-SA 4.0. Every commit requires a human DCO 1.1 sign-off. Contributors retain their copyright; the DCO does not assign it.

Security reports and sensitive conduct concerns never belong in public issues. Community support is best effort and no service-level commitment is implied.

Current limitation: the initiative has not yet appointed the independent conduct recipients or second critical-change maintainer required for full public operation. Critical contributions remain blocked until independent review exists.