Counter-selection (candidates deliberately excluded) has no machine-readable home in the schema

[realmarcin]

Found reviewing #305, which had to choose between two bad options and took the least-bad one.

What #305 ran into

SynCom_ARC (CommunityMech:000314) is defined by a counter-selection: candidate Bacillus isolates that inhibited Bradyrhizobium were excluded, so the shipped community is the subset of effective antifungal strains that spares the nitrogen-fixing mutualist. That constraint is the whole design.

There were only two places to put it:

• As an ecological_interaction — machine-readable, but wrong. The excluded and retained isolates are indistinguishable at the genus-level grounding the source supports, so the typed edge asserts that an ARC member antagonises the mutualist ARC was built to spare (Genus-level grounding conflates included and excluded strains in SynCom ARC (000314) #300).
• As engineering_design.notes prose — accurate, but invisible to any consumer reading the graph.

#305 chose prose. That is right for this record, and it means the fact is no longer queryable at all.

The general gap

The schema can express what a community is but not what it was deliberately not. There is nowhere to record:

• candidate members screened out, and on what criterion;
• a compatibility constraint that shaped assembly;
• a negative result that is load-bearing for the design.

This is not rare in engineered communities — screening is how most SynComs are built, and "we excluded X because it antagonised Y" is often the most informative sentence in the paper. Right now it either becomes a misleading edge or disappears into prose.

Worth noting the audit is not neutral here either: removing the edge left the record with only COMMUNITY_LEVEL interactions, which the auditor credits with no connections, so it gained DISCONNECTED findings (#304). The honest modelling choice is currently penalised twice.

Sketch

A counter_selection block on CommunityEngineeringDesign, multivalued, each entry carrying an excluded TaxonDescriptor (where resolution allows), the criterion, and evidence. That keeps it out of ecological_interactions — these are not interactions within the community, since the excluded strains are not in it — while making it queryable and evidence-backed like everything else.

Open questions: whether excluded candidates should also appear in taxonomy (probably not — they are not members), and how to represent an exclusion whose subjects cannot be resolved apart from the retained members, which is exactly ARC's situation.

Related: #300 (the instance), #304 (the audit penalty), #294 (same shape — the KB cannot distinguish "ruled out" from "absent").

[realmarcin]

A written proposal covering this issue together with the other two in its theme is open as PR #309 (proposals/absence_semantics.md).

The three share a diagnosis — the schema can say "has value X" or "is empty", so empty is overloaded across not-done, impossible, undecidable, and deliberately-excluded — but the proposal argues they need three different remedies, and can be decided independently.

Context measured for this issue: 193 records carry engineering_design but only 40 carry free-text notes, so most have nowhere at all for a load-bearing negative result.

The proposal sketches a counter_selection block on CommunityEngineeringDesign with excluded_taxon optional — SynCom ARC is precisely the case where excluded strains cannot be distinguished from retained ones at the resolution the source supports.

[realmarcin]

The proposal is merged — proposals/absence_semantics.md on main (PR #309).

It records the shared diagnosis (one blank column encoding four different situations: impossible, undecidable, deliberately withheld, accidentally stale), argues the three issues need different remedies rather than one mechanism, and states the concrete design for this one.