Surfaced by the review of #355 (which closed #334). Pre-existing and #352's shape, but #355 is what turned it from an inconsistency into something with consequences.
The inconsistency
proton_motive_force appears across the corpus with four different node_types:
| node_type |
records |
STATE |
morphology/gliding.yaml, physiology/carboxydotrophic.yaml |
BIOLOGICAL_PROCESS |
metabolism/electron_transfer.yaml, environment/ph_delta_mid1.yaml, environment/ph_optimum_mid2.yaml, environment/aerobic.yaml |
CHEMICAL |
metabolism/metabolism.yaml, metabolism/oxygenic_photosynthesis.yaml |
CAPACITY |
physiology/phototrophic.yaml |
It is one concept — an electrochemical proton gradient across the membrane — described in much the same words in each record.
Why it matters now
#355 minted METPO:2007900 (powers) gated to subject_types = BIOLOGICAL_PROCESS|STATE, object_types = GENE_OR_PROTEIN. Two byte-identical assertions now behave differently purely because of how their subject node is typed:
physiology/carboxydotrophic.yaml proton_motive_force (STATE) -> atp_synthase (GENE_OR_PROTEIN) grounds
physiology/phototrophic.yaml proton_motive_force (CAPACITY) -> atp_synthase (GENE_OR_PROTEIN) blocked_by_node_type
That is visible in reports/predicate_grounding_residual.tsv as powers … 4 blocked_by_node_type. Three of those four are blocked correctly — their objects are processes, and an energetic driver feeding a process satisfies enables' range and belongs there. The phototrophic.yaml one is blocked only by the typing disagreement.
A gate is the right mechanism; what is wrong is that the corpus does not agree with itself about what the subject is.
What to decide
Which type is correct, then normalise. CHEMICAL looks clearly wrong — a gradient is not a chemical species. Between STATE and BIOLOGICAL_PROCESS there is a real question: the gradient is a state, while generating and maintaining it is a process, and different records may legitimately mean different ones. CAPACITY is the outlier and is likely just wrong.
Related: #352 tracks the same class of defect for capacity to X nodes, and DUPLICATE_GROUNDING/DISPOSITION_MISTYPED in audit-graphs detect neighbouring cases. A check that flags one node_id carrying multiple node_types across records would catch this whole family, and does not exist yet.
Not urgent: nothing is mis-grounded today, and the one blocked edge fails closed rather than open.
Surfaced by the review of #355 (which closed #334). Pre-existing and #352's shape, but #355 is what turned it from an inconsistency into something with consequences.
The inconsistency
proton_motive_forceappears across the corpus with four differentnode_types:STATEmorphology/gliding.yaml,physiology/carboxydotrophic.yamlBIOLOGICAL_PROCESSmetabolism/electron_transfer.yaml,environment/ph_delta_mid1.yaml,environment/ph_optimum_mid2.yaml,environment/aerobic.yamlCHEMICALmetabolism/metabolism.yaml,metabolism/oxygenic_photosynthesis.yamlCAPACITYphysiology/phototrophic.yamlIt is one concept — an electrochemical proton gradient across the membrane — described in much the same words in each record.
Why it matters now
#355 minted
METPO:2007900(powers) gated tosubject_types = BIOLOGICAL_PROCESS|STATE,object_types = GENE_OR_PROTEIN. Two byte-identical assertions now behave differently purely because of how their subject node is typed:That is visible in
reports/predicate_grounding_residual.tsvaspowers … 4 blocked_by_node_type. Three of those four are blocked correctly — their objects are processes, and an energetic driver feeding a process satisfiesenables' range and belongs there. Thephototrophic.yamlone is blocked only by the typing disagreement.A gate is the right mechanism; what is wrong is that the corpus does not agree with itself about what the subject is.
What to decide
Which type is correct, then normalise.
CHEMICALlooks clearly wrong — a gradient is not a chemical species. BetweenSTATEandBIOLOGICAL_PROCESSthere is a real question: the gradient is a state, while generating and maintaining it is a process, and different records may legitimately mean different ones.CAPACITYis the outlier and is likely just wrong.Related: #352 tracks the same class of defect for
capacity to Xnodes, andDUPLICATE_GROUNDING/DISPOSITION_MISTYPEDinaudit-graphsdetect neighbouring cases. A check that flags onenode_idcarrying multiplenode_types across records would catch this whole family, and does not exist yet.Not urgent: nothing is mis-grounded today, and the one blocked edge fails closed rather than open.