Move ARC's counter-selection out of the interaction graph (#300) - #305
Merged
Conversation
Network integrity findingsReporting only — this check does not fail the build (see issue #273). The full report is attached to the workflow run as an artifact. |
There was a problem hiding this comment.
Pull request overview
This PR updates the curated community record CommunityMech:000314 (SynCom ARC) to prevent a misleading pairwise interaction from appearing in the ecological interaction graph when the paper cannot distinguish included vs excluded Bacillus isolates at the available taxonomic resolution.
Changes:
- Moves the “counter-selection / excluded candidate strains inhibited Bradyrhizobium” fact from a typed PAIRWISE COMPETITION edge into
engineering_design.notes+engineering_design.evidence. - Updates the Bradyrhizobium taxon note to point readers to the design-level counter-selection record.
- Removes the misleading pairwise interaction entry so the remaining graph only contains genuine
COMMUNITY_LEVELeffects.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
127
to
+131
| notes: The nitrogen-fixing symbiont whose compatibility constrained community assembly, and | ||
| whose nodulation ARC is designed to induce. Not an inoculated ARC member; it is the mutualist | ||
| the community must not antagonise. | ||
| the community must not antagonise. The counter-selection that excluded Bradyrhizobium- | ||
| antagonising candidates is recorded under engineering_design, not as an interaction — see the | ||
| note there. |
CommunityMech:000314 carried a typed Bacillus -> Bradyrhizobium COMPETITION edge recording that three candidate Bacillus isolates inhibited the rhizobium and were excluded from the community on that basis. The problem is resolution. The source names the retained isolates but not the excluded ones, so both sets ground to the same genus-level NCBITaxon:1386. A consumer reading only the typed edges therefore saw a community whose own member antagonises the very mutualist the community was assembled to spare — the exact opposite of the finding. Prose caveats on the interaction did not help, because the misleading claim is in the graph, not the prose. CommunityEngineeringDesign already has `notes` and `evidence`, so the fact moves there with its snippet intact and an explanation of why it is not an interaction. Nothing is lost: the counter-selection is what explains the community's membership, and it is now recorded where it belongs — as a property of the design rather than as a relation between two taxa. The Bradyrhizobium taxon note points at it so the connection is findable from either end. No schema change was needed, which was option 3 of the three in #300. Trade-off, measured: removing the pairwise edge leaves the record with only COMMUNITY_LEVEL interactions, and the auditor credits those with no connections at all, so network findings go 34 -> 36. Both new ones are DISCONNECTED, the soft category. Filed as #304, because the underlying rule turns out to reward unsourced metadata — a taxon is exempt from DISCONNECTED if it carries abundance_level or functional_role, so removing the fabricated abundances from this record (correctly, in #298's review) is itself what exposed its taxa. That is sharper evidence for the policy question #273 has to settle. Record still passes schema and id<->label; 10 snippets verbatim. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
realmarcin
force-pushed
the
arc-exclusion-modeling-300
branch
from
August 3, 2026 03:34
d60ec5f to
512b8ed
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #300.
The problem was in the graph, not the prose
CommunityMech:000314carried a typedBacillus → BradyrhizobiumCOMPETITION edge recording that three candidate Bacillus isolates inhibited the rhizobium and were excluded from the community on that basis.The source names the retained isolates but not the excluded ones, so both sets ground to the same genus-level
NCBITaxon:1386. A consumer reading only the typed edges therefore saw a community whose own member antagonises the very mutualist it was assembled to spare — the exact opposite of the finding.The record already carried
supports: PARTIALand explanatory notes. That did not help: the misleading claim lives in the graph, and prose beside it does not reach anyone consuming the edges.Where it went instead
CommunityEngineeringDesignalready hasnotesandevidence, so the counter-selection moves there with its snippet intact and an explanation of why it is not an interaction. No schema change was needed — this is option 3 of the three in #300.Nothing is lost. The exclusion is what explains the community's membership, and it is now recorded as a property of the design rather than as a relation between two taxa. The Bradyrhizobium taxon note points at it, so the connection is findable from either end.
Measured trade-off, and what it exposed
Removing the pairwise edge leaves the record with only
COMMUNITY_LEVELinteractions, which the auditor credits with no connections at all. Network findings go 34 → 36; both new ones areDISCONNECTED, the soft category.Chasing that down produced a sharper finding, filed as #304: the
DISCONNECTEDrule exempts any taxon carryingabundance_levelorfunctional_role(auditor.py:258). So removing this record's fabricated abundance values — correctly, during #298's review — is itself what exposed its taxa. The audit currently scores a record better for carrying invented abundances than for honestly omitting them.That also explains why 107 of 302 all-
COMMUNITY_LEVELrecords do not already flood the audit: the exemption is doing the work, not the connectivity check. It is concrete evidence for the policy question #273 has to settle before that gate can be restored.Verification
🤖 Generated with Claude Code
Review round
Rebased onto main so this runs against the snippet-truncation gate from #303; the record passes it.
Three things checked rather than assumed, none of which turned into a change:
Is the counter-selection snippet now duplicated? It appears twice — on
engineering_design.evidenceand on the Bradyrhizobium taxon entry. That is not a defect: 269 of 307 records (88%) reuse a snippet across assertions, because one sentence legitimately supports several claims. Here the two uses are genuinely different — one records the design constraint, the other records why Bradyrhizobium is in the record at all.Does removing the edge create an inconsistency with other records? Searching for interactions describing exclusion found six candidates, and all six are false positives on inspection —
Paraburkholderia Competitive Exclusionis genuine ecological competitive exclusion, "excludes non-acidophilic contaminants" is an environmental effect, "excludes direct cell contact" describes an experimental control. No other record models a screening result as an interaction, so ARC was unique and this fix does not leave the KB inconsistent.Is
supports: SUPPORTright on the moved evidence? The original edge carriedPARTIAL, correctly, because the snippet did not fully support the interaction claim it was attached to. Moved onto the design, the snippet directly states the fact it now supports — three isolates antagonised the rhizobium — soSUPPORTis the accurate level. The change in level is principled, not a relaxation.One consequence worth recording
The fact is now accurate but no longer machine-queryable. A consumer asking "which communities involve Bradyrhizobium antagonism" will not find ARC through the graph, because the only faithful place to put the constraint was prose.
That is the right trade for this record and the wrong situation in general: the schema can express what a community is but not what it was deliberately not — no home for screened-out candidates, compatibility constraints, or load-bearing negative results, which is how most SynComs are actually built. Filed as #307 with a
counter_selectionsketch. Combined with #304, the honest modelling choice is currently penalised twice: it loses queryability and gainsDISCONNECTEDfindings.899 tests pass; lint clean; record passes schema and id↔label.