METPO proposal v8: trait-realization and electron-role predicates (#302, #303)

[realmarcin]

Implements the "mint METPO terms" decision for the #301/#302/#303 cluster.

The problem, in one line

The corpus has no range-correct relation whose object is a trait, and both
available candidates are wrong in opposite directions.

• RO:0002327 (enables) has been filling the gap. The repo's own vendored
  data/raw/biolink-model.yaml:5099-5110 gives it range
  'biological process or activity'; a TRAIT node is a disposition, so each of
  164 edges entails trait ⊑ BiologicalProcessOrActivity (164 enables edges point at TRAIT nodes, violating RO:0002327's range — and the enables mapping row is ungated #302).
• METPO's chemical-interaction predicates (METPO:2000008/2000009 + 64 siblings)
  are transitively subPropertyOf METPO:2000001, whose rdfs:domain is
  microbe. CausalNodeTypeEnum has no organism member, so no causal-graph
  edge can ever satisfy it (366 causal-graph edges assert microbe-domain METPO predicates on non-organism subjects #301).

That squeeze is exactly what forced PR #300 to reverse 15 electron edges onto
enables, collapsing donor and acceptor onto one relation and losing the role
for 7 of them (#303).

What this proposes

Cohort proposals/metpo_traitmech_v8/, three predicates, following the v1
convention of domain = range = METPO:1007401 (trait causal node) — the choice
that sidesteps the microbe domain and the process range at once:

ID	Label	Edges	Records
METPO:2007700	confers	146	114
METPO:2007701	has electron donor	13	13
METPO:2007702	has electron acceptor	5	3

The partition is exhaustive and verified: 146 + 13 + 5 = 164, computed by
walking every causal_graphs[].edges[] and cross-checked against the
independently-derived ENABLES_RANGE_ON_TRAIT count in
reports/predicate_domain_audit.tsv (the audit added in #314).

The donor/acceptor pair deliberately reverses direction back to
<trait> has electron donor <chemical> — restoring what METPO:2000008/2000009
expressed before their organism domain made them unusable here. That reversal is
what lets one relation per role replace one generic relation, so
dissimilatory_iron_reduction's two acceptor edges stop being indistinguishable
from its donor-shaped edge.

What was checked

• just verify-proposal metpo_traitmech_v8 → PASS (failures: 0).
• just robot-validate-proposal metpo_traitmech_v8 → PASS: template compiles,
  merges with metpo.owl, ELK reasons with no UNSAT (+6 axioms, matching v6's
  delta for a comparable cohort).
• just qc green; uv run pytest → 420 passed; ruff clean.
• Every definition_source anchor verified to be a real graph_id in the cited
  file. Cross-ontology alignments live in xrefs + metpo_proposal_mappings.sssom.tsv
  as skos:closeMatch, never in definition_source (Emit cross-ontology equivalents as mappings, not definition_source, in METPO proposals #83).
• ID-block collision checked against v1–v7 and CommunityMech v1; 2007700 is free,
  and the highest real minted METPO property is METPO:2000516.

Also fixed here: #318

Building this cohort hit a pre-existing bug. verify_metpo_proposal's Scope-A
check ran even for cohorts shipping no classes template, so class_tsv_text was
"" and every corpus traitmech: id read as uncited — failing every
predicate-only cohort (v2, v4, v6) once the corpus gained its first synthetic id.
The script already printed "Scope C/A check will skip" for that case and
check_scope_c already honoured it; only Scope-A did not.

Fixed, with 4 regression tests. The fix was canaried against the pre-fix code:
the key test fails without the guard and passes with it, so it genuinely bites.
v1 and v7 still fail this check — correctly, because 120 synthetic ids really are
un-lifted, which is filed separately as #319.

Scope: proposal only

No corpus edges are grounded here. #301 warns that doing the whole sweep at once
would be unreviewable, so the 164-edge migration follows as a separate PR,
where the proof of landing is ENABLES_RANGE_ON_TRAIT falling 164 → 0 in the
ratcheted audit. The placeholder IDs are not minted upstream yet; the round-trip
plan is in proposal.md.

Closes nothing on its own — #302 and #303 stay open until the migration lands.

🤖 Generated with Claude Code

[culturebot-reviewer]

Claude finished @realmarcin's task in 6m 5s —— View job

---

Review: METPO proposal v8

The mechanical parts hold up. What I verified independently:

• METPO:1007401 = trait causal node (v1 classes template) ✅
• METPO:2000008 = uses as electron acceptor, METPO:2000009 = uses as electron donor, both subPropertyOf METPO:2000001, whose rdfs:domain is METPO:1000525 = microbe (data/raw/metpo.owl:159-163, 265-285, 3913-3919) ✅ — the 366 causal-graph edges assert microbe-domain METPO predicates on non-organism subjects #301 argument is real
• enables range = biological process or activity (data/raw/biolink-model.yaml:5098-5110) ✅
• 164 ENABLES_RANGE_ON_TRAIT rows in reports/predicate_domain_audit.tsv ✅
• Highest minted METPO property is METPO:2000516; 2007700–2007702 clear of v1–v7 and of any existing confers-labelled term ✅
• All three definition_source anchors are real graph_ids and each really does carry an enables→TRAIT edge ✅
• Subset tag metpo_traitmech_2026_11 is the next in sequence after v7's _10 ✅
• No data/traits/** changes, so no history/ record is owed ✅

The three problems below are all in prose that gets copy-pasted upstream (the observations column of the ROBOT template), so they matter more than their size suggests.

---

🟡 The confers subject-type breakdown sums to 142, not 146

metpo_proposal_properties_robot.tsv:3 (and proposal.md:71-73):

BIOLOGICAL_PROCESS 81, GENE_OR_PROTEIN 32, ENVIRONMENTAL_FACTOR 12, QUALITY 5, CELLULAR_LOCALIZATION 5, PATHWAY 4, CHEMICAL 4, MOLECULAR_FUNCTION 2, STATE 1

81+32+12+5+5+4+2+1 = 142, against a claimed 146 edges. Either four subjects have a type not in the list (undeclared node → node_type None?) or one of the two numbers is wrong. Since the 146+13+5=164 identity is the load-bearing claim of the whole cohort, this needs resolving rather than papering over. If the four are untyped, say so explicitly — that's itself a corpus finding.

Fix this →

🟡 The dissimilatory_iron_reduction narrative is factually wrong

metpo_proposal_properties_robot.tsv:5, proposal.md:105-106, and the PR body:

two reversed acceptor edges became indistinguishable in predicate terms from a pre-existing donor-shaped edge

DIR has exactly one causal graph and exactly three enables→dir_trait edges (data/traits/metabolism/dissimilatory_iron_reduction.yaml:90, 133, 148): ferric_iron, solid_fe3_mineral, dissolved_fe3_om_complex. All three are Fe(III) species, and the file's own node descriptions call them terminal electron acceptors ("Terminal electron acceptor reduced in DIR", line 48). There is no donor edge in DIR. The file's 2026-08-05 curation note says the reversed edges "share a predicate with the donor convention" — the corpus-wide convention, not a DIR edge; that got compressed into "its donor-shaped edge" and lost its meaning.

The cohort's own arithmetic confirms it: 5 acceptor edges across 3 records only closes as DIR×3 + oxygen_preference + dissimilatory_metal_reduction. So the partition already treats all three DIR edges as acceptors, and the prose contradicts it. A METPO curator reading this observations cell will look for a donor edge in DIR and not find one.

Fix this →

🟡 One has electron acceptor object is not a chemical species

The only 5-edge/3-record partition consistent with the corpus puts oxygen_preference.yaml#oxygen_terminal_electron_acceptor under METPO:2007702. That node is:

node_type: MOLECULAR_FUNCTION
label: O2 as terminal electron acceptor
description: Use of molecular oxygen as the terminal electron acceptor of the respiratory chain.

(data/traits/environment/oxygen_preference.yaml:71-76)

It is a function, not a chemical, so <trait> has electron acceptor <the use of O2 as an acceptor> doesn't satisfy the proposed definition ("a relation between a trait ... and a chemical species"). Either that edge belongs in confers — which reads fine — or the node should be retyped to CHEMICAL and grounded to CHEBI:15379, in which case say so and note it as migration work. Please confirm which of the 164 edges actually land in each bucket; right now the partition is only inferrable from the counts.

Fix this →

🔵 The OWL range is weaker than the definitions promise

domain = range = METPO:1007401 for all three is the v1 convention and correctly dodges both the microbe domain and the process range. But it means has electron donor/has electron acceptor are unconstrained on the object side, while their definitions say "a chemical species". You already plan to gate this in predicate_grounding.tsv (proposal.md:181-183); worth stating in the proposal so upstream doesn't read the range as tight.

---

The verify_metpo_proposal.py fix (#318)

Correct and minimal. main() already prints "classes TSV: missing (Scope C/A check will skip)" at scripts/verify_metpo_proposal.py:207 and check_scope_c already honours the same condition at line 160-162 — the guard just makes Scope-A agree with what the script already said it would do. The four tests are the right ones, and the second (test_scope_a_still_fires_for_a_classes_cohort) is what stops the fix from being a blanket disarm.

Unrelated to this PR, but missing = sorted(i for i in ids if i not in class_tsv_text) (line 144) is a substring match — traitmech:000001 is satisfied by a cell containing traitmech:0000010. Pre-existing; mentioning it only because you're in the file.

---

Not run in this environment: just verify-proposal, just robot-validate-proposal, and uv run pytest all require approvals this sandbox didn't grant, so I could not independently confirm the PASS / no-UNSAT / 420-passed claims. Everything above was verified by reading the corpus, the audit report, metpo.owl and biolink-model.yaml directly.

---

• Read repo conventions
• Review proposal files (CURIEs, labels, mappings, ID block)
• Verify the edge partition against the corpus
• Review verify_metpo_proposal.py fix + tests
• Post verdict — changes requested
  · branch

[culturebot-reviewer]

Three accuracy problems in text that ships upstream to METPO; the ID hygiene, ontology grounding and the verify_metpo_proposal fix all check out. Details in the review comment: #320 (comment)

[realmarcin]

Thanks — three of the four findings were real and are fixed; one does not hold. Detail below, with what I verified against the corpus in each case.

🟡 DIR narrative — valid, fixed

You're right, and the error was mine. All three of DIR's Fe(III) species are terminal electron acceptors — data/traits/metabolism/dissimilatory_iron_reduction.yaml's own node descriptions say so ("Terminal electron acceptor reduced in DIR") — so there is no donor-shaped edge in that graph. I had compressed the file's curation note about the corpus-wide donor convention into a claim about a DIR edge, exactly as you diagnosed.

Rewritten in both the observations cell and proposal.md: the real #303 loss is that after PR #300 reversed two of them onto enables, nothing in predicate terms records the acceptor role at all.

🟡 oxygen_preference — inference was wrong, but the underlying ask was right

That edge is not in the acceptor bucket. Its node is typed MOLECULAR_FUNCTION ("O2 as terminal electron acceptor" denotes the use of O2, not O2 itself), and my classifier requires a CHEMICAL subject for the role-bearing pair — so it lands in confers, as one of the two MOLECULAR_FUNCTION subjects. The actual 5 acceptor edges are DIR×3 + dissimilatory_metal_reduction + dissimilatory_manganese_reduction, which is the 5-edges/3-records partition.

But your underlying point stands — the partition was only inferrable from counts. I've published the explicit 164-edge partition as an appendix (every donor and acceptor edge listed by record, confers broken out by node type), and called out the oxygen_preference typing explicitly, including that retyping it to CHEMICAL/CHEBI:15379 is defensible but is corpus work for the migration PR.

🔵 OWL range weaker than the definitions — valid, added

New subsection saying so plainly, plus why tightening was rejected (committing the range to CHEBI re-imports the cross-ontology coupling the v1 METPO:1007401 convention exists to avoid) and that the constraint is enforced data-side via subject_types/object_types.

🔴 The 142-vs-146 arithmetic — does not hold

The published breakdown has nine terms, not eight:

BIOLOGICAL_PROCESS 81 + GENE_OR_PROTEIN 32 + ENVIRONMENTAL_FACTOR 12
+ QUALITY 5 + CELLULAR_LOCALIZATION 5 + PATHWAY 4 + CHEMICAL 4
+ MOLECULAR_FUNCTION 2 + STATE 1  =  146

The review's tally 81+32+12+5+5+4+2+1 omits CHEMICAL 4 and so reaches 142. Recomputed from the corpus and left unchanged; the new appendix shows the same nine rows summing to 146, so it's now checkable rather than asserted. No untyped subjects exist in this set.

Also

• Fixed this cohort's own Scope-A row, which repeated v2's now-stale "none in corpus" claim — there are 120, tracked in 120 traitmech: synthetic ids in the corpus are not lifted by any METPO cohort #319. Good prompt to re-read my own table.
• Your substring-match observation on check_scope_a is real and pre-existing; filed as verify_metpo_proposal's Scope-A coverage test is a substring match, so a longer id satisfies a shorter one #321 rather than widening this PR.

Re-verified after the changes: just verify-proposal PASS (0 failures), just robot-validate-proposal PASS (no UNSAT, +6), just qc green, 420 tests pass. Understood that this sandbox couldn't run those independently.

[culturebot-reviewer]

Claude finished @realmarcin's task in 3m 13s —— View job

---

Re-review: METPO proposal v8 (commit 2dd3a6ce) — approved

All three real findings are resolved, and the fourth was mine to withdraw.

🔴→ withdrawn: the 142-vs-146 arithmetic

You're right and I was wrong. 81+32+12+5+5+4+**4**+2+1 = 146 — my tally dropped CHEMICAL 4. The published breakdown was correct as written. Nothing to change.

Verified against the corpus

The partition is real, not asserted. I walked the audit rows for each bucket:

• 5 acceptor edges / 3 records — dissimilatory_iron_reduction (ferric_iron, solid_fe3_mineral, dissolved_fe3_om_complex), dissimilatory_manganese_reduction (mn_iv_oxide), dissimilatory_metal_reduction (metal_terminal_acceptor). All five subjects are node_type: CHEMICAL, so the "a chemical species" definition holds for every member. The other enables→TRAIT edge in DMR (anoxia) correctly falls to confers.
• 13 donor edges / 13 records — one per record across the lithotrophy/organotrophy family. chemoorganoheterotrophic contributes two enables→TRAIT edges and only the chemical one (organic_molecule) is in the donor bucket; substrate_transport_system goes to confers. That's the distinction the count depends on and it's made correctly.
• 146 = 164 − 18 is therefore forced, independent of the node-type breakdown.

The appendix labels match the corpus character-for-character, including the near-collision between chemolithotrophic's "inorganic chemical electron donor" and chemolithoheterotrophic's "inorganic chemical donor" — both node id inorganic_chemical_donor. And the stated regeneration rule ("label or edge description names the role") is exactly what separates mn_iv_oxide and organic_molecule from their siblings; I checked those two edge descriptions and the rule bites as written.

oxygen_preference — you were right, I inferred wrong. The node is MOLECULAR_FUNCTION, your classifier requires a CHEMICAL subject, so it lands in confers. My 5-edge reconstruction had substituted it for dissimilatory_manganese_reduction. The appendix now says this explicitly and flags the CHEBI:15379 retyping as migration work, which is the right place for it.

DIR narrative (metpo_proposal_properties_robot.tsv:5, proposal.md:105-113) is now accurate on every point I can check: all three edges are <Fe(III) species> enables dir_trait, all three nodes describe terminal acceptors, and "once two of them were reversed onto enables by PR #300" matches the record's REVERSE_CAUSAL_EDGE_DIRECTION note at line 202-215 — ferric_iron was already enables, exactly two were reversed. The claim that the acceptor role now survives only in free text is the correct reading of #303.

OWL range subsection — states the gap plainly and gives the reason tightening was rejected. mappings/predicate_grounding.tsv does carry subject_types/object_types columns, so the data-side enforcement it points to exists.

Scope-A row — good catch on your own table; the corrected row no longer contradicts #319.

Not re-verified

Same sandbox limits as before: python3 and gh issue view both require approvals this environment didn't grant, so I could not recompute the nine-way node_type breakdown of the 146 confers edges edge-by-edge, nor confirm #319/#321 exist. The 146 total is confirmed by subtraction; the internal split is the one number still resting on your run. Everything else above came from reading reports/predicate_domain_audit.tsv, the trait YAMLs and the proposal directly.

---

• Re-read the changed proposal files
• Re-check the 142-vs-146 arithmetic — my error, withdrawn
• Verify the DIR narrative rewrite against the corpus
• Verify the published 164-edge partition
• Check the OWL-range subsection and Scope-A row fix
• Post verdict — approve
  · branch

[culturebot-reviewer]

Re-reviewed after 2dd3a6c. All three prior findings are resolved and verified against the corpus; the 142-vs-146 finding was my arithmetic error (I dropped CHEMICAL 4) and the published tally is correct. Details in #320 (comment)