GOVERNANCE.md

Governance

AntiFlock is governed as safety-sensitive open-source infrastructure. The current name is an internal working title and is not cleared for public launch; governance under this file does not claim a trademark or affiliation with any existing project.

Roles

• Contributors propose code, documentation, research, reports, and review.
• Maintainers merge changes, cut releases, and steward one or more domains.
• Security and privacy maintainers review identity, authorization, privileged execution, evidence, data collection, retention, community abuse, and Scrambler changes.
• Project lead resolves decisions that remain blocked after documented alternatives and objections. Until named in the repository, this role is held by the repository owner and may not be inferred from commit access.

Repository permissions are not permission to override safety contracts.

Current accounts

The repository currently has two collaborators:

• AetherAI3 — repository admin. This account authors most changes and runs the project's automation; treat it as the bot/author account.
• dbarrante — write access. This is the human maintainer.

Both accounts are operated by the same person today. See the independence rule below for what that means for review.

Decisions

Routine, reversible changes use normal review. Architecture, wire-compatibility, privacy, security, evidence semantics, community-safety, naming, and governance changes require an ADR or equivalent design record with consequences and explicit domain-maintainer approval. Maintainers seek rough consensus, record material objections, and favor the narrower, privacy-preserving, reversible choice when evidence is incomplete.

No maintainer may unilaterally:

• weaken the prohibition on tracking or targeting people;
• permit equipment interference, harassment, or automatic evasion routes;
• put model output into the blocking path;
• upload exact continuous location or collect payloads by default;
• make truthful evidence semantics subscription-dependent;
• bypass signed plans, verification, or rollback for Scrambler; or
• publicly launch under the working name without documented clearance.

The main gate

main is the only release branch. It is protected by a GitHub repository ruleset, not classic branch protection: ruleset 21237783, "Protect main release gate", enforcement active, target ~DEFAULT_BRANCH. Anyone can read it with gh api repos/AetherAI3/AntiFlock/rulesets/21237783. As of 2026-08-23 it enforces exactly the following; this document is updated in the same pull request as any change to the ruleset.

Bypass actors: none. No account, app, role, or team may bypass the ruleset, including repository admins.

Branch rules:

• deletion blocked;
• non-fast-forward (force) pushes blocked;
• linear history required (squash or rebase merges only; merge commits are refused).

Pull-request rule:

• at least 1 approving review;
• approval of the last push is required (a new push after approval invalidates it);
• stale reviews are dismissed on push;
• every review thread must be resolved;
• changes with unattributed commits require an extra approval;
• allowed merge methods: squash and rebase;
• code-owner review is not required (.github/CODEOWNERS is advisory and drives reviewer assignment only).

Required status checks, strict (the branch must be up to date with main before merging), by exact context name:

Context	Workflow / job
Protobuf contracts	ci.yml → contracts
Go 1.26.6	ci.yml → go (gofmt, tidy, test, race, vet, staticcheck, govulncheck)
Node.js 24 workspaces	ci.yml → javascript
Android reference JVM tests	ci.yml → android
Strict acceptance gates	ci.yml → acceptance (ten-gate strict harness)
analyze (go)	codeql.yml → analyze matrix
analyze (javascript-typescript)	codeql.yml → analyze matrix
scan	gitleaks.yml → scan (full-history secret scan)

Because the contexts are matched by name, renaming a CI job, or changing the Go version in the Go 1.26.6 job name, silently detaches the required check until the ruleset is edited in the same change. Do not rename these jobs without updating the ruleset and this table together.

Additional workflows (dependency-review.yml, release.yml, and any adversarial gate) are advisory until they are added to the ruleset; adding a context to the ruleset is a governance change recorded here.

Independence rule

A review counts as the approving review only when it is independent of the change:

• Two accounts operated by the same person are one reviewer. Approval from dbarrante on a pull request authored by AetherAI3 (or the reverse) satisfies the ruleset mechanically but is not independent security review, and is recorded as self-review in the controller ledger that accompanies each merge train. Until a second, unaffiliated maintainer exists, every merge to main is self-reviewed and the project says so plainly in SECURITY.md.
• Reviews produced by AI agents or automated reviewers are advisory evidence. They may be attached to a pull request and cited, but they are never the approving review and never substitute for a human maintainer.
• A reviewer who authored any commit in the pull request is not independent for that pull request.

The ruleset enforces the mechanics; this rule governs what the mechanics may be taken to mean.

Changes and releases

All changes are reviewed through branches and pull requests against main; nobody pushes to main directly. A release requires passing tests, schema compatibility review, dependency and artifact provenance, known-risk notes, and security/privacy sign-off proportional to the touched surface. Critical findings block release unless the project lead and security maintainers document an explicit, time-bounded exception that does not put users or third parties at unreasonable risk.

Generated contracts derive from the checked-in protobuf sources. Published field or enum numbers are never reused. Security corrections remain visible in history; confidential exploit detail may be embargoed until coordinated disclosure.

Release baseline

No release-qualified tag exists yet. v0.1.0-alpha marks an engineering completion boundary and predates this gate; it is not a supported release.

The first release-qualified tag will be cut only from a main commit whose required status checks (all eight contexts above) passed on that exact SHA. A green run on a predecessor commit, on a pull-request merge ref, or on a rebased copy of the same diff does not qualify. release.yml checks this mechanically and refuses to build otherwise; see docs/release-policy.md for the flow, artifact set, and rollback rules.

Release signing

Release artifacts are signed with sigstore cosign, keyless, using the GitHub Actions OIDC identity of release.yml on this repository. There is no long-lived signing key to lose or rotate; verification pins the certificate identity https://github.com/AetherAI3/AntiFlock/.github/workflows/release.yml@refs/tags/<tag> and the issuer https://token.actions.githubusercontent.com. A signature made by any other identity, including a maintainer's personal key, is not a release signature.

SBOM and checksums

Every artifact set ships with a CycloneDX JSON SBOM generated by syft (anchore/sbom-action, pinned by commit) and a SHA256SUMS file covering every binary and the SBOM. SHA256SUMS is the signed object; a cosign provenance attestation binds it to the source commit, the workflow ref, and the Go toolchain. Consumers verify the bundle, then the checksums, then use the binaries; any other order proves nothing.

Supply chain

• Every GitHub Action is pinned to a full commit SHA with a version comment. Dependabot (.github/dependabot.yml) proposes pin updates weekly.
• New Go module dependencies require maintainer sign-off in the pull request and must pass govulncheck and the dependency-review workflow.
• Release builds use -trimpath -buildvcs=true with CGO disabled so the binary records the exact source revision and whether the tree was clean.
• Release workflows use only the ephemeral GITHUB_TOKEN and OIDC token. There are no repository secrets involved in building, signing, or publishing.

Community intelligence moderation

Moderation follows docs/community-intelligence-policy.md. Reports are judged by evidence, public-interest value, privacy, freshness, and safety rather than commercial tier or viewpoint. Appeals and corrections are documented. Access to non-public reporter information is least-privilege and audited.

Conflicts and conduct

Maintainers disclose material employment, financial, vendor, dataset, or personal conflicts and recuse when impartial review is doubtful. Conduct is governed by CODE_OF_CONDUCT.md. Retaliation for good-faith security, privacy, or safety concerns is prohibited.

Amendments

Governance amendments require a public proposal, review period once a public community exists, approval by a majority of active maintainers including one security/privacy maintainer, and a recorded decision. Before that body exists, the repository owner may bootstrap roles but may not weaken the locked safety boundaries above, and may not add bypass actors to the main ruleset.