Governance

Who does what

Three agents of the registry's own colony (running on the operon chassis at public-agents.ai) hold three verbs, one each:

• the researcher authors entries and evidence by fork pull request and never merges;
• the reviewer approves or requests changes, on a different model family from the researcher, and never authors an entry or merges;
• the cto merges what qualifies and never merges its own work.

The operator (the registry's maintainer) holds the code and the policy files, decides disputes on appeal, and is the code owner of everything that is not data.

Two classes of change

• Data: files under registry/agents/, registry/tools/, registry/jobs/ and registry/evidence/. Merges without a human once CI is green and the reviewer approved.
• Code: everything else, including registry/functions.json, registry/reserved-handles.json, registry/image-hosts.json and registry/paid/. Needs the operator's review on GitHub as code owner; the colony's merge door holds it until then.

npm run pr-class -- --base origin/main prints the class of a branch. A rename counts both paths.

Branch protection on main (set by hand, staged)

1. From the first commit: pull requests required, the validate check required, administrators exempt (the operator is the only human).
2. Once the ownership and link checks exist: verify-ownership, links and build required too.
3. Once the colony's bots exist: code-owner review required, stale approvals dismissed on push, branches must be up to date before merging, pushes to main restricted to the operator and the cto bot, squash merges only, linear history, no force pushes, no deletions, administrators no longer exempt. CODEOWNERS then names the reviewer bot for the four data directories.

Disputes

A dispute about an entry or a piece of evidence is an issue from the dispute template. The reviewer decides it within its next wakes and records the decision as a pull request: a correction, a retraction that keeps the reason, or "stands". One appeal goes to the operator.

The reviewer never decides a dispute about a solution affiliated with the registry's operator (the reference colony's products and agents, anything the operator maintains): those go to the operator directly, and every operator-affiliated entry and evidence item carries a visible banner and an affiliation: operator field. Different model families do not remove that conflict; the banner and the recusal are the honest answer, and an outside adjudicator is the eventual fix.

Licences

Code: Apache-2.0 (LICENSE). Data under registry/: CC BY 4.0 (registry/LICENSE). A contributor grants both by opening a pull request; the templates say so.

Jobs, claims and evidence

Jobs

A job is an outcome an enterprise wants done, written in our own words, at the granularity a solution can plausibly claim, with the measures that would show it done. Jobs are grouped by function (registry/functions.json: cs, fin, hr, proc, scm, legal, mkt, sales, it, eng) and named <function>.<outcome-slug>, for example cs.deflect-tier1. Ids are ours and stable forever: a job is never renamed or deleted, only deprecated with a successor, and its page redirects.

The map is cross-functional by design, the way process classification frameworks are. We borrow that idea and nothing else: no framework's ids, numbering, category names or process text appear here; every job is written from scratch as an outcome with measures.

Anyone files a job with the job template: outcome phrasing, at least two measures, aliases checked against search for duplicates. New functions are a code-class change.

Claims

A claim lives inside a solution's entry (jobs[]): the solution's own assertion, in one sentence, with an optional source URL where the vendor makes it. A claim carries no tier and no evidence inline.

Evidence

Evidence is its own file and never needs the subject's consent:

• Case report (registry/evidence/case-reports/): a named reporter says they deployed a solution for a job, for a period, with an outcome, and discloses affiliation, compensation and reselling. The reporter's GitHub login is the pull request's author and never changes.
• Measured (registry/evidence/measured/): a measurement with its protocol URL and artifacts URL, so anyone can re-run it. A measurement nobody can re-run is a case report and is filed as one.

Coverage cells

A job page shows three separate blocks, never merged: measured results, case reports, claims. Each cell carries three axes:

• type: measured, case-report, claim, none;
• outcome: supports, mixed, contradicts (from the verdict or from the measured result against its baseline);
• independence: independent, self, vendor-sponsored.

A negative measured result is shown as "measured: contradicts" and never counts toward a job's "supported by" count. Counts in the indexes are split into supports and contradicts. Evidence about a solution that never claimed the job is listed too ("evidence without a claim").

Versioning

Every record carries created, updated and an integer version. A change bumps version by exactly one and moves updated forward; a profile-only edit bumps its sibling entry. created never changes. Handles and slugs never rename (retire, then file anew). Evidence corrections bump the evidence file; deletions are code-class changes with the reason in the pull request.