Mosaic Showcase Queries

The queries Mosaic was built for sit in the KG-native section first. These are the 2nd- and 3rd-order R&D questions that a flat retrieval layer over the same sources cannot answer — they require typed traversal across multiple graph hops.

The basic section below collects the 1st-order lookups (single target, single compound, single org). They're still useful as on-ramps; they're not what makes the graph valuable.

Sample outputs are excerpts of real tool responses with long arrays trimmed. Schemas mirror src/db/queries.py and src/mcp/responses.py exactly. The auto-generated reference for every parameter and every field is at mcp_tools_reference.md.

KG-Native Queries

These are the headline queries. Each pairs a strategic R&D question with the traversal Mosaic actually performs and the tool that returns the result.

1. Synthetic-lethal whitespace for a drugged target

Query: "For KRAS, which functionally-coupled partners are still development whitespace?"

Why it's hard. Synthetic-lethal partners aren't a list anywhere — they're the intersection of (a) co-essentiality (DepMap CRISPR), (b) shared pathway / PPI signal (Reactome + STRING), and (c) the absence of patent / clinical activity on the partner. No single database answers this. A generic LLM cites textbook pairs (KRAS/SHP2, KRAS/SOS1) and stops.

What Mosaic does. mosaic_synthetic_lethal_whitespace unions DepMap Mosaic-vs-all-genes coessentiality with STRING-ext PPI + Reactome shared-pathway edges, then partitions the result by whether the partner's competitive status can be measured at all:

• candidates — partner is inside the curated universe, so its patent and compound counts are real. Filtered to < 5 patents and no clinical compound, ranked by coupling × 1/(1+patents) × (1 + ln(1+validation)).
• coupled_unassessed — partner is outside the universe. Patent/compound counts come from targets-keyed tables, so for these genes they are absent, not zero. They carry null counts and no whitespace score, and are ranked by coupling strength alone.

That split is the whole point: applied as one flat filter, patents < 5 is vacuously true for every gene we don't cover, so the tool would rank the genes it knows least about at the top and call them uncontested.

Tool call:

mosaic_synthetic_lethal_whitespace({
  approved_target: "KRAS",
  limit: 20,
})

Sample output (excerpt):

{
  "anchors": ["KRAS"],
  "candidates": [
    {
      "anchor": { "symbol": "KRAS", "druggability_tier": "tier1" },
      "whitespace_partner": {
        "symbol": "WRN", "in_mosaic_kg": true,
        "patent_count": 3, "compound_count": 1, "validation_evidence": 24
      },
      "co_essentiality_r": 0.62,
      "co_functionality_basis": "depmap_coessentiality",
      "whitespace_score": 0.74,
      "suggested_approach":
        "Combination: KRAS G12C inhibitor + WRN modulation in MSI-high CRC; …"
    }
    // PRMT5, SLFN11, …
  ],
  "coupled_unassessed": [
    {
      "whitespace_partner": {
        "symbol": "RBM10", "in_mosaic_kg": false, "out_of_coverage": true,
        "not_assessed_reason": "gene outside Mosaic curated coverage",
        "patent_count": null, "compound_count": null
      },
      "coupling_strength": 0.41,
      "whitespace_score": null
    }
  ],
  "coverage_note": "coupled_unassessed partners are outside the curated universe: competitive status unknown, not zero. Do not describe them as uncontested.",
  "method": "DepMap Mosaic-vs-all-genes coessentiality where available, else PPI + shared-pathway proxy",
  "candidates_using_real_coessentiality": 3
}

Visual: <SyntheticLethalPairCard /> renders each pair side-by-side with a strength bar, drug-status badges, and a per-row "Watch this pair" action.

2. Resistance-bypass landscape for a drugged target

Query: "Which resistance-implicated targets for EGFR therapy are under-developed?"

Why it's hard. Resistance mechanisms accumulate in scattered papers; the bypass tracks (MET amp, AXL upregulation, NRG1 fusions, …) are widely discussed but the under-developed nodes — the small-team plays — only emerge when you cross-reference resistance literature against current compound / patent activity. Pure LLM recall surfaces the textbook MET track and stops.

What Mosaic does. mosaic_resistance_bypass_map aggregates resistance_relations edges (keyword-mined from literature; GLiREL has no resistance type yet — documented limitation) by bypass target, augments with STRING-ext high-confidence PPI partners, ranks by drugability_gap = evidence_papers × avg_confidence × 1/(1+patents).

Tool call:

mosaic_resistance_bypass_map({ target: "EGFR" })

Sample output (excerpt):

{
  "target": "EGFR",
  "bypass_candidates": [
    {
      "bypass_target": {
        "symbol": "MET", "patent_count": 8, "compound_count": 16,
        "max_clinical_phase": 3
      },
      "evidence_source": "resistance_relations",
      "resistance_evidence_papers": 14,
      "resistance_kinds": ["bypass_signalling", "amplification"],
      "avg_confidence": 0.78,
      "drugability_gap_score": 1.21,
      "evidence_snippet":
        "MET amplification is a recurrent mechanism of acquired resistance to …"
    },
    // AXL (mid-tier), BRAF, NRG1 (under-served), STK11 (PPI-only)
  ],
  "method": "Resistance co-mentions (curated literature) + STRING PPI extended partners"
}

Visual: <ResistanceBypassDiagram /> renders an SVG flow from the primary target through mechanism-of-resistance nodes to each bypass target, with confidence-tinted edges.

3. Modality gaps in a target family

Query: "Which bromodomain targets lack covalent / degrader / macrocycle chemistry?"

Why it's hard. Modality coverage isn't queryable from any single source — it's a per-target classification over the top-ranked compounds. Asking "which modalities are absent across the BET family" requires SMILES classification on each target's chemistry, then a comparison across the family. Generic LLMs answer from training-data recency and miss recent degraders.

What Mosaic does. mosaic_modality_gaps runs a heuristic SMILES modality classifier (small_molecule, covalent, degrader, macrocycle, peptide_like) over each target's top-ranked compounds and reports explored vs absent. Family rollup is by stacking multiple target-level calls (targets.protein_family is unpopulated upstream — documented).

Tool call:

mosaic_modality_gaps({ target_or_family: "BRD4" })
// Per target across the BET family: BRD2, BRD3, BRD4, BRDT

Sample output (excerpt):

{
  "query": "BRD4",
  "resolved_target": "BRD4",
  "explored": {
    "small_molecule": 412,
    "degrader": 26,
    "unclassified": 71
  },
  "absent_modalities": ["covalent", "macrocycle", "peptide_like"],
  "unclassified_compounds": 71,
  "note": "Heuristic SMILES on top-ranked compounds; target-level only."
}

Cross-family signal. Stacked across BRD2 / BRD3 / BRD4 / BRDT, covalent and macrocycle are absent across all four — those are the modality whitespaces in the family.

Visual: <ModalityGapsMatrix /> renders the family × modality grid with filled cells clickable into the compound list and a "Most-gapped" auto-summary at the foot.

4. Researcher / talent migration on a target

Query: "Who works on KRAS, and what else are they publishing on lately?"

Why it's hard. Author identity needs to be resolved (persons table with ORCID + name fuzzy match), recency needs to be weighted, the "also works on" signal needs to be a separate cross-target join — and patents need to flow through inventor records, not author records. No single bibliographic database does all of that across paper + patent surfaces.

What Mosaic does. mosaic_talent_migration joins paper_mentions_target ⋈ paper_authors and patent_mentions_target ⋈ patent_inventors per person, weights by Σ (paper_year - window_start + 1), and for each researcher returns their other targets in the same window.

Tool call:

mosaic_talent_migration({ target: "KRAS", lookback_years: 5 })

Sample output (excerpt):

{
  "target": "KRAS",
  "lookback_years": 5,
  "researchers": [
    {
      "name": "Frank McCormick",
      "orcid": "0000-0001-0000-0001",
      "affiliation": "UCSF",
      "papers_on_target": 18, "patents_on_target": 3,
      "recency_weight": 84,
      "also_works_on": [
        { "target": "SHP2", "last_year": 2025, "papers": 7, "patents": 1 },
        { "target": "SOS1", "last_year": 2024, "papers": 4, "patents": 2 }
      ]
    }
    // …
  ]
}

Privacy. Individual names render in the UI only on explicit "Show contributors" expansion, and only when ≥2 researchers support a destination — k-anonymity-lite.

Visual: <TalentMigrationView /> — aggregate destination bars with an eye-toggle that reveals contributors past the k≥2 floor.

5. Emerging-activity signal detection

Query: "Which oncology targets have surging paper activity in the last six months?"

Why it's hard. "Trending" sites and PubMed advanced search give surface signal but not the comparison against each target's own baseline. A target with 30 papers/month that goes to 38 is meaningless; the same +30% on a target that historically gets 2 papers/month is a real surge. Per-target z-scores require monthly time-series per target.

What Mosaic does. mosaic_emerging_signals buckets paper_mentions_target / patent_mentions_target rows into year-months, computes baseline (mean + stdev of prior-window sums) and recent-window sum per target, returns targets with z > 2 plus an inline sparkline.

Tool call:

mosaic_emerging_signals({
  window_months: 6,
  signal_type: "paper_surge",
  limit: 20,
})

Sample output (excerpt):

{
  "signal_type": "paper_surge",
  "window_months": 6,
  "signals": [
    { "target": "SHP2", "z_score": 4.6, "recent_window_count": 38,
      "baseline_mean": 12.4,
      "sparkline": [10,14,9,11,13,12,11,10,12,14,13,11,38,42,31,28,35,36] },
    { "target": "MTA2", "z_score": 3.1, "recent_window_count": 9,
      "baseline_mean": 2.1,
      "sparkline": [1,2,2,1,3,2,1,0,2,3,4,3,7,9,8,6,5,9] }
    // …
  ]
}

Visual: <EmergingSignalsList /> renders each row with an inline sparkline (recent window tinted) and a z-tone chip (≥4 rose, ≥3 amber, ≥2 primary).

6. Structurally similar targets (paralog / fold-analog discovery)

Query: "What targets are structurally similar to BRAF? I want to know about scaffold-hopping opportunities."

Why it's hard. Sequence-level paralogs (BLAST hits) are easy. Structural paralogs — proteins with shared fold despite low sequence identity — are exactly what scaffold-hopping medicinal chemistry needs, and require an all-vs-all comparison over AlphaFold structures with TM-score. Without a pre-computed index that's a multi-hour Foldseek run per query.

What Mosaic does. mosaic_find_similar_targets reads from a pre-built target_structure_neighbors index (Foldseek 3Di+AA all-vs-all over the 320 AlphaFold PDB corpus, indexed by scripts/build_foldseek_index.py). Returns top-K with TM-score normalised over query length, alntmscore over alignment length, evalue, lddt, rmsd.

Tool call:

mosaic_find_similar_targets({ gene: "BRAF", k: 10 })

Sample output (excerpt):

{
  "target": "BRAF",
  "neighbors": [
    {
      "neighbor": {
        "symbol": "RAF1", "name": "RAF1 proto-oncogene",
        "target_class": "Kinase", "druggability_tier": "tier1"
      },
      "tm_score": 0.94, "alntmscore": 0.96, "evalue": 1.2e-180,
      "lddt": 0.91, "rmsd": 0.81
    }
    // ARAF, KSR1, KSR2, … RAF-family fold homologs
  ],
  "k": 10, "index_loaded": true,
  "method": "Foldseek 3Di+AA all-vs-all over AlphaFold PDBs; tm_score normalised over query length"
}

Note. Until the operator runs python -m scripts.build_foldseek_index once (Docker + Foldseek, ~5–15 min on the 320-PDB corpus), the tool returns an empty list with index_loaded: false and a build-the-index hint instead of failing. Differentiator over Gosset.ai's KOL-and-literature angle — they have no structural-similarity story.

Basic Queries (1st-order, single-entity lookups)

These are the 10 queries the platform shipped Move-1 with. They're useful but they don't traverse the graph — flat retrieval over the same sources could in principle answer them. They live below the KG-native section because the graph isn't where their value comes from.

The full parameter and response reference for every tool — KG-native and basic — is at mcp_tools_reference.md, regenerated from the server definitions.

Usage

These queries work across every Mosaic surface:

• Agent chat — natural language at https://getmosaic.dev (web) or the embedded chat
• MCP client — Claude Desktop, Claude Code, Cursor, any MCP-compatible client connected to mcp.getmosaic.dev
• HTTP API — POST /agent/query with { "query": "…" }
• MCP server direct — tool-call payloads over stdio or SSE

Each query typically completes in 1–3 seconds. Cost depends on the response length — the data is free from Mosaic; the Claude tokens that route + summarize the response cost ~$0.05–0.10 per call.

Case studies

For end-to-end worked examples (the question, the graph reasoning step-by-step, the rendered output, limitations) see:

• /case-studies/kras-g12c-synthetic-lethal
• /case-studies/egfr-resistance-bypass
• /case-studies/bromodomain-modality-gaps