23 interaction participants are deliberately absent from taxonomy, shielded from the gate only by scope: COMMUNITY_LEVEL

[realmarcin]

Found reviewing PR #316. A curation-policy question, not a code defect.

UNKNOWN_SOURCE/UNKNOWN_TARGET are error-severity (they gate), and are suppressed only when the interaction carries scope: COMMUNITY_LEVEL. Schema makes scope optional with ifabsent: string(PAIRWISE).

Scanning the KB: 23 interaction participants across 17 records name organisms deliberately absent from taxonomy — hosts (Medicago truncatula (host legume), Arabidopsis thaliana, Lactuca sativa (lettuce host)), pathogens (Rhizoctonia solani, Aeromonas hydrophila), and umbrella placeholders (anode, three-species model community). Every one escapes the gate solely because its interaction is COMMUNITY_LEVEL.

Verified: deleting the scope key from the one interaction in Rice_Duckweed_Bacillus_SynCom.yaml yields 2 error findings and exit 3 — a red build on a record that is otherwise correct.

Arguably the gate is behaving correctly (a PAIRWISE edge to a non-member is dangling). But it means the gate has a 23-case blast radius behind a single optional key, and the underlying question is unresolved: should hosts and antagonists be taxonomy members? #307's counter-selection proposal asks the mirror-image question about excluded candidates, and its recommendation there was "no".

Worth deciding deliberately rather than discovering via a red build.

[realmarcin]

Decision recorded (2026-08-03, from the maintainer, in a working session).

Hosts and antagonists become taxonomy members. They are participants in the system the record describes, so they belong in the membership list rather than being reachable only through an interaction slot.

The NCBITaxon:2 aggregate placeholders do not. They are the community naming itself — "three-species model community", "core floodplain bacteria", "Drosophila five-species bacterial microbiota" — or, in one case, "anode", an electrode grounded as Bacteria. On a COMMUNITY_LEVEL interaction the scope already asserts the relation holds across the community, so the participant slot adds nothing; it is dropped, and the wording is already carried by each interaction's description.

---

Corrected counts (2026-08-03). An earlier version of this comment gave 13 and 14. Those came from the auditor's matching rule, not the one this comment stated, and are wrong for the curation question. Re-measured over all 1127 participant slots in 312 records:

criterion	non-placeholder	NCBITaxon:2	total
A — the id appears nowhere in that record's taxonomy	10 slots / 8 records	13 slots / 8 records	23 / 16
B — unresolved by the auditor (no name match and the id is not unique)	13 / 9	14 / 9	27 / 18

A is the criterion for this decision, and it reproduces the 23 in the issue body exactly (only the record count moved, 17 → 16, after #345). A participant whose id is already in taxonomy is a member, however the record spells its name.

The four extra slots in B are name variants of existing members — "Olsenella (Actinobacteriota)" against NCBITaxon:133926 listed twice, "Variovorax" against a taxon listed six times, "Bacillus SynCom" against one listed four times, and Saanich Inlet's aggregate. They need a rename or nothing, not a new taxonomy entry, and "Bacillus SynCom" is an aggregate that belongs with the placeholders.

So the work is: add 10 host/antagonist entries (each needing a grounded term and a snippet), drop 13 placeholder slots, and reconcile 4 name variants. Per-record evidence curation, so not suitable for an unattended loop — see NEXT_TASKS_LOOP.md.