SPEC-193 — External Platform Parity

Master parity spec for external science platforms and v2 capability comparisons.

Source: docs/design/spec-193-external-platform-parity.md

SPEC-193: External Platform Parity Master

Field Value
Status Draft v1
Owner kris.ganjam@outlook.com
Date 2026-05-20
Pillar Both (Substrate + Prism)

Adjacent context:

  • SPEC-015 — v1 → v2 parity tracking (the internal parity backbone)

  • SPEC-039 — v1 → v2 engagement parity (closes the same gap at the UI density layer)

  • SPEC-197 — where v2 should exceed peers, not just match

This spec is the external parity counterpart. SPEC-015/039 ask “are we at v1 parity?” — SPEC-193 asks “are we at peer-platform parity?” — SPEC-197 asks “where do we own ground v1 and peers don’t?”

TL;DR

Three peer platforms operate in the same conceptual space as v2 SciDEX and either compete for the same researcher attention or set the bar for what an artifact-centric scientific platform looks like in 2026:

  1. beach.science — hypothesis-first community platform with 6,479 longevity entries, coves (topic groups), pixel-art beach aesthetic, dual human/agent auth, falsification-criteria template, auto-generated mechanism/readout infographics. Direct competitor for hypothesis surface area. → SPEC-194

  2. Biomni (Stanford) — general-purpose biomedical AI agent; 150 specialized tools, 105 software packages, 59 databases; Biomni-AD won a $1M Alzheimer prize; Biomni Lab is the integrated workspace. Direct competitor for agent tooling depth. → SPEC-195

  3. K-Dense — already vendored at vendor/kdense-skills, vendor/mimeo, vendor/mimeographs; the source of v2’s content surfaces (skills as artifacts per SPEC-013, mimeos per SPEC-027/SPEC-182). Reference partner, not competitor — parity here means “we exercise their primitives faithfully.” → SPEC-196

This umbrella spec exists because v2 cutover decisions need an honest answer to “would a researcher prefer beach.science / Biomni / k-dense to v2 for this workflow?” — and that answer needs evidence, not vibes.

1. Why this is a separate parity track from SPEC-015/039

SPEC-015 / SPEC-039 (v1 parity) SPEC-193 (external parity)
Target SciDEX-AI/SciDEX (own legacy code, frozen) beach.science, Biomni, K-Dense
Access Read v1 source + DB directly Black-box: scrape, API where available, paper readings
Acceptance parity_target rows = verified Side-by-side workflow walkthroughs documented
Cutover gate Yes (must-have parity gates cutover) No — informs roadmap, not cutover
Cadence Pre-cutover; freezes after Continuous; peers ship features that move the bar

Mixing them was a temptation we resisted: v1 parity is a completed exercise (1,618 of 1,619 targets DONE), but external parity is a standing engagement — peers will ship things in June that move what “parity” means.

2. Inventory method

Per-subspec, but the shared shape is:

  1. Cold reconnaissance — fetch the public-facing surface (HTML / API docs / GitHub / paper) without authentication.

  2. Capability cataloging — every visible feature gets a row: name, evidence (URL / screenshot / repo path), v2 mapping (verb / artifact type / page).

  3. Gap classification — for each row, mark one of:

    • MATCHED — v2 has direct equivalent

    • MISSING — no v2 equivalent; need to decide port vs retire vs counter

    • INFERIOR — v2 has equivalent but theirs is better (specific axes: latency, UX, completeness, depth)

    • SUPERIOR — v2 has equivalent and ours is better (feeds SPEC-197)

    • ORTHOGONAL — feature is theirs to own (not in scope for v2 mission)

  4. Quarterly refresh — rerun the recon every 90d; track drift.

Output schema (per-subspec): a markdown table + per-row parity_target artifact (extending SPEC-015’s schema with a peer_platform field).

3. Subspec dispatch

Subspec Platform Recon owner Implementation owner First-pass status
SPEC-194 beach.science this spec TBD Inventory drafted; gaps unclassified
SPEC-195 Biomni this spec TBD Inventory from paper + repo; toolset overlap mapped
SPEC-196 K-Dense this spec TBD Submodule diff against vendored versions; checks mimeo policy adherence

4. Acceptance for this umbrella spec

  • Three subspecs created (194/195/196)

  • Each subspec has a ## Capability inventory section with ≥10 rows

  • Each subspec has classified ≥80% of rows (MATCHED / MISSING / INFERIOR / SUPERIOR / ORTHOGONAL)

  • At least one concrete cross-platform parity test ships in tests/integration/external_parity/

  • docs/operations/v2-rc-checklist.md references this spec in the engagement-parity section

  • Quarterly-refresh ritual scheduled (mechanism TBD: cron quest if Orchestra reactivated, else manual reminder in v2-rc-checklist)

5. Non-goals

  • Replicating peer UI 1:1. We borrow patterns selectively (per SPEC-039 §1.4) but don’t surrender our identity to look like beach.science.

  • Forking peer code. K-Dense submodules are intentional reuse; Biomni/beach.science are reference reads, not vendored.

  • Gating cutover on external parity. v1 parity gates cutover; external parity informs what we ship in the months after.

6. Open questions

  • Should parity_target schema get a peer_platform enum, or is a separate external_parity_target cleaner? (Lean: extend, don’t fork — single inventory table is easier to query.)

  • For beach.science: do we treat their 6,479 longevity hypotheses as a seed corpus we should mirror (with attribution), or only as a structural reference? (Lean: structural — mirroring is an SPC-014 / Forgejo artifact-store question, not this spec’s call.)

  • For Biomni: their 150-tool list is published; should v2 expose a scidex.tools.list verb that includes a biomni_equivalent field per tool? (Lean: yes, but as part of SPEC-195 not here.)

Revision log

  • 2026-05-20: Initial draft. Loop iter 1 (parity-quest scaffolding pass).