After looking more broadly than I did last time, I think I found quite a lot of existing work that PathMap may be able to borrow from:
I think the PDEV + modifier + target + disease idea is a good direction. The one architectural change I would make early is to treat the “periodic table” / graph as a view, not as the source-of-truth data model.
Underneath it, I would keep something closer to:
Entity
↓
Material / Preparation
↓
Process
↓
Observation
↓
Assertion + Evidence
↓
CandidateAssembly
↓
MissingBridge / CompetingAssembly / NextExperiment
Then the same records can generate the three views you described:
- clinical-needs view: disease → tissue/cell/axis → delivery constraints → PDEV/modifier/payload candidates
- nutrition view: plant/food → native material/cargo → oral/gut interactions → pathways/diseases
- bioinformatics view: target/pathway → supported components → missing bridges → candidate assemblies → discriminating experiment
So I would keep one canonical ginger / STAT3 / ovarian-cancer object rather than triplicating entities, and generate different projections from it.
The practical reason is that a “ginger EV” is not necessarily one stable object with one size, charge, cargo profile or activity. MISEV2023 puts substantial emphasis on source material, preprocessing, separation, characterization and storage. A useful 2025 ginger comparison also found that ultracentrifugation, sucrose-gradient UC, membrane filtration and PEG precipitation changed not only yield but stability, metabolomic composition and in-vitro activity (Ming et al., 2025).
So my low-cost default route would be:
- keep your PDEV / modifier / target / disease concept;
- add preparation/process/context as first-class data;
- store measurements as observations rather than universal plant properties;
- separate scientific assertions from their evidence;
- generate the periodic-table/graph UI from those records;
- then add a CandidateAssembly object for the PathMap-style cases where most pieces are supported but the exact integrated configuration is not.
That last object may be especially useful for PathMap.
For the datapoints you listed, this is roughly how I would store them
Most of these look safer as contextual observations than fixed properties.
| Datapoint |
Store roughly as |
Important context |
| Plant/PDEV source |
species + tissue + source material |
cultivar/harvest state when reported |
| Preparation |
preprocessing → isolation/separation → purification → storage |
probably first-class |
| Vesicle identity |
reported term + normalized term + characterization evidence |
plant-EV nomenclature is still evolving |
| Size |
distribution + method + medium + time |
not just one mean diameter |
| Concentration/yield |
particles/mL or particles/g + method |
preparation-dependent |
| Charge |
zeta potential + medium + pH/ionic conditions + method |
not just “negative” |
| Native cargo |
molecule + assay + abundance if available + preparation |
detection ≠ functional delivery |
| Engineered payload |
cargo + loading process + efficiency/capacity + release/retention + functional assay |
preparation/process-specific |
| Modifier |
modifier + modification process + localization/attachment evidence + post-modification characterization |
entity + transformation |
| Binding |
target + assay + context |
distinguish association/receptor binding/internalization |
| Uptake |
cell/tissue + dose + time + assay |
uptake ≠ functional cargo delivery |
| Innate mechanism |
assertion + pathway + cell/species/disease context + evidence |
avoid universalizing context-specific effects |
| Delivery route |
route + formulation + dose + schedule |
critical for biodistribution |
| Biodistribution |
tissue × time × route × dose × detection method |
preferably a time series |
| Clearance |
PK-like observations + formulation + assay + organs/time |
size alone is not enough |
| Disease/target |
normalized ID + tissue/cell/phenotype context |
useful for joins |
| Evidence |
PMID/DOI + supporting passage/figure/table when possible + study type + context |
makes every edge auditable |
| Contradiction |
assertion A challenges B under context C |
better than calling a whole paper “contradictory” |
For maximum payload size, I would avoid a hard field such as:
ginger_EV.max_payload_size = X
unless a paper really establishes such a limit. The EV-loading literature shows that cargo chemistry, vesicle composition and loading method all matter; incubation, electroporation, sonication, extrusion, freeze-thaw and transfection can have very different performance and effects on vesicle integrity (EV cargo-loading overview; reporting proposal for exogenous EV cargo loading). A systematic review of plant-derived EV drug-delivery studies likewise shows substantial variation across cargos and preparations.
I would therefore store demonstrated loading capability:
vesicle_preparation
cargo_type / identity / length or MW
loading_method
vesicle:cargo ratio
loading_efficiency / loading_capacity
free-cargo removal
post-loading size / charge
integrity
retention / release
functional-delivery assay
evidence
The same logic applies to biodistribution/clearance. A systematic review of EV biodistribution found strong size/time trends but also major methodological heterogeneity, so I would treat route, source, formulation, dose, surface properties and time as part of the observation rather than infer clearance from size alone.
I would also keep these predicates separate:
ASSOCIATES_WITH
INTERNALIZED_BY
DELIVERS_CARGO_TO
MODULATES_TARGET
CHANGES_PHENOTYPE
IMPROVES_DISEASE_ENDPOINT
because fluorescent association with a tissue is much weaker evidence than intact-vesicle delivery, functional intracellular cargo delivery, target modulation, or disease improvement.
Useful reporting standards and a small v0.1 schema
I would borrow fields rather than invent everything from scratch:
- MISEV2023 — source material, preprocessing, separation, characterization, storage and functional claims.
- EV-TRACK — methodological reporting turned into a queryable EV knowledgebase.
- MIFlowCyt-EV — useful if single-EV flow data are included; separates preanalytics, preparation, controls, calibration and reporting.
- MIRIBEL — especially useful for engineered PDEVs because it separates material characterization, biological characterization and experimental protocol.
- ISEV Plant EV Task Force — plant-specific nomenclature/standardization is still moving, so keeping both the author’s original term and a versioned normalized mapping seems safer than freezing an ontology too early.
A small schema could begin with only:
Entity
Material
Process
Observation
Assertion
Evidence
CandidateAssembly
For example:
{
"material_id": "MAT:GINGER:ROOT:PREP_001",
"source": {
"organism": "Zingiber officinale",
"tissue": "rhizome"
},
"preparation": {
"preprocessing": [],
"separation": [],
"purification": [],
"storage": {}
},
"reported_names": [
"ginger-derived extracellular vesicles",
"ginger-derived exosome-like nanoparticles"
],
"observations": [
{
"type": "particle_size_distribution",
"method": "NTA",
"conditions": {},
"evidence_id": "EVID:..."
}
]
}
Transformations can then be explicit:
Material A
--[load siRNA by electroporation]-->
Material B
--[surface modification]-->
Material C
--[encapsulation in hydrogel]-->
Formulation D
That preserves how the engineered object actually came into existence instead of reducing everything to:
ginger_EV HAS_MODIFIER X
For normalization, existing vocabularies can carry much of the boring work: NCBI Taxonomy, NCBI Gene, ChEBI, PubChem, Mondo, Reactome, Gene Ontology, UBERON and Cell Ontology.
I would still preserve the original free-text label beside every normalized ID.
The PathMap-specific layer I would explore: CandidateAssembly
The broader search made me think the interesting unit is not merely a hidden A–B relation, but an untested integrated assembly.
PathMap dataset #134 already comes close to this in prose: it distinguishes evidence for individual GDEV / hydrogel / permeability-related components from the exact integrated configuration that remains untested.
I would make that distinction machine-readable:
CandidateAssembly
├── components
├── intended_context
├── required_commitments
├── supporting_evidence
├── challenging_evidence
├── context_compatibility
├── prior_art_status
├── missing_bridges
├── competing_assemblies
└── candidate_experiments
For example, an assembly involving a carrier + modifier + hydrogel + route + disease context might require:
C1 modifier can be attached/associated reproducibly
C2 modification preserves vesicle integrity/function
C3 hydrogel releases functional vesicles
C4 route/formulation reaches the intended compartment
C5 modifier improves the intended transport property there
C6 native/loaded therapeutic mechanism remains active
C7 integrated system has acceptable off-target effects/toxicity
The key distinction is:
support for C1–C7 individually is not support for the exact assembly.
That sounds obvious, but making it explicit is useful because compositional biomedical ideas can fail at a single interface.
It also gives PathMap a more informative output than one plausibility score:
Six commitments have direct/near-direct support; two are unresolved. The highest-risk bridge is X. Experiment Y would test that bridge and distinguish the leading alternatives.
A compact object could look like:
{
"assembly_id": "PA:000123",
"components": [
{"role": "carrier", "id": "..."},
{"role": "payload", "id": "..."},
{"role": "modifier", "id": "..."},
{"role": "formulation", "id": "..."}
],
"context": {
"disease": "...",
"species": "...",
"tissue": "...",
"cell_type": "...",
"route": "..."
},
"required_commitments": [
{
"id": "C1",
"assertion": "...",
"status": "supported|partial|unknown|challenged",
"evidence_ids": [],
"challenge_ids": [],
"context_match": "high|medium|low|unknown"
}
],
"prior_art": {
"exact": [],
"near": [],
"subassembly": [],
"bridge": [],
"searched_at": "...",
"search_protocol": "..."
},
"competing_assemblies": [],
"experiments": []
}
The graph can then be generated as a projection:
component ↔ assembly
evidence ↔ assertion
assertion ↔ commitment
commitment ↔ experiment
assembly ↔ disease/target/modifier
without making the projection itself the authoritative scientific record.
A lot of adjacent work can probably be borrowed
I found enough neighboring work that I would actively reuse concepts rather than design every layer independently.
Claims/evidence/context: INDRA and EMMAA
INDRA separates typed scientific Statements from one or more Evidence objects, including citations, source text, annotations and biological context. That is very close to what a PDEV claim graph needs.
EMMAA incrementally incorporates new literature and resolves exact/partial redundancy during assembly; its model-testing framework can rerun tests as models change. This is a useful precedent for making a PathMap discovery a living object rather than a frozen report.
Whole-vs-parts feasibility: DARPA SciFy
DARPA’s Scientific Feasibility (SciFy) program is particularly close conceptually. It decomposes capability claims into constituent verifiable parts, while explicitly noting that parts being possible does not establish feasibility of the whole: integration, logical consistency and compatibility can still matter.
That is almost exactly the failure mode a multi-component PDEV assembly has to guard against.
Mechanistic/model composition: Big Mechanism / ASKEM
DARPA’s Big Mechanism targeted reading fragmented biomedical literature and assembling causal mechanisms. ASKEM goes further into heterogeneous scientific knowledge, model composition/decomposition, simulation and traceability.
So I would not define PathMap’s distinction simply as “combining components.” A narrower and more useful target may be tracking the required commitments of a proposed experimental/therapeutic assembly.
Prior-art/contradiction search: FutureHouse / PaperQA2
FutureHouse’s science agents include a precedent-search agent intended for “Has anyone done X before?” questions. Their open-source PaperQA2 is also useful implementation precedent for iterative literature retrieval, evidence extraction and cited synthesis, and includes contradiction-search tooling.
Closed-loop discovery: Robin
The 2026 Nature paper on Robin links literature search, hypothesis generation, proposed experiments, human wet-lab work, data analysis and updated hypotheses.
So “closing the scientific loop” by itself is already becoming an occupied space. A complementary PathMap role could be to produce an auditable assembly dossier that a human researcher or later experimental agent can consume.
Competing hypotheses and discriminating measurements
A much older AI precedent is Reiter’s model-based diagnosis: keep competing explanations and choose measurements that distinguish them.
The domain is different, but the pattern maps well to:
Assembly A: modifier improves uptake
Assembly B: modifier adds nothing
Assembly C: modifier destabilizes vesicle
followed by:
Which inexpensive measurement best separates A/B/C?
Novelty, ranking, and the next experiment
I would make novelty a search state, not a Boolean scientific property.
Instead of:
novel = true
something like:
EXACT: no match found
NEAR: 3 matches
SUBASSEMBLY: 12 matches
BRIDGE: partial precedent
searched_at: 2026-08-28
sources: [...]
query_families: [...]
coverage_limitations: [...]
Then the public wording can be:
No exact prior art was found under this search protocol as of DATE.
That is stronger scientifically than “this has never been done,” because synonymy, full text, patents, trial registries, conference material and database coverage can all defeat a simple novelty search.
This caution also has precedent in LBD evaluation. A 2023 Bioinformatics analysis describes weaknesses in evaluating literature-based discoveries using a small set of famous retrospective cases or later co-occurrence as a gold standard.
For ranking, I would therefore look at:
support_directness
context_compatibility
contradiction_severity
evidence_independence
missing_bridge_count
missing_bridge_severity
prior_art_distance
experimental_tractability
and keep bridge count separate from bridge severity. One unresolved question such as “does this reach the relevant spinal motor neurons?” may be much more serious than three cheap formulation-compatibility questions.
For experiments, I would rank not only “what tests the hypothesis?” but:
Which experiment removes the most uncertainty or best distinguishes the leading assemblies?
A candidate experiment could carry:
tests_commitments
discriminates_assemblies
expected_outcomes_by_hypothesis
cost_class
time_class
technical_complexity
Then a cheap integrity/loading assay can outrank an animal study if it can already falsify the whole assembly.
Finally, I would benchmark the system before scaling it:
- known-prior-art test — can it avoid calling established assemblies new?
- retrospective bridge test — using literature only up to year N, can it identify bridges later experimentally supported?
- adversarial assembly test — all components are individually supported, but their integration fails because of route/context/loading/formulation/etc.
- context-vs-contradiction test — can it distinguish genuine conflict from different species/cells/doses/preparations/endpoints?
- experiment-selection test — does its top experiment actually discriminate alternatives better than a generic next step?
Those seem more informative than simply counting generated hypotheses.
A small v0.1 would probably be enough to learn whether this structure is useful:
- manually curate 20–50 well-documented PDEV preparations;
- preserve preparation/process/context/evidence;
- generate the three views from one canonical dataset;
- add 5–10 CandidateAssemblies with only a few unresolved bridges;
- run exact/near/subassembly/bridge precedent searches;
- see whether PathMap can clearly answer:
What is directly known?
What is inferred?
What is challenged?
What exact combination was searched?
What bridge is still missing?
What cheap experiment would resolve the most uncertainty?
That would keep the project very close to the direction you already seem to be exploring rather than turning it into a different system.
The “periodic table” idea can remain the friendly interface. The main change would be to give it a preparation- and evidence-aware source of truth underneath.
And the PathMap-specific design target I would personally explore is this:
a near-complete experimental assembly whose individual commitments, evidence, context, contradictions, prior-art search, missing bridges, competing variants and next discriminating experiment are tracked together.
I would be cautious about claiming that exact combination is unprecedented—the neighboring fields are broad and moving quickly—but it looks like a useful object even if every individual piece has prior art elsewhere.