OMICS
SERVICE CONTRACT · VIEW: GOV
Axiom
OMICS governs multi-omic intelligence. Every signature evidenced. Every variant classified. Every analysis ledgered.
Constraints
MUST: Compose all three primitives (INTEL + CHAT + COIN) MUST: Evidence-back every omic finding (GOLD/SILVER/BRONZE) MUST: Classify variants per ACMG/AMP standards MUST: Version all bioinformatics pipelines MUST: Trace gene expression signatures to source datasets (GEO series ID) MUST: Distinguish research-use from clinical-grade results MUST: Gate clinical decision support behind credentialed practitioners MUST: Ledger every analysis event (dataset, method, result, timestamp) MUST: Cite source databases with accession numbers MUST: Support temporal reclassification (variant evidence evolves) MUST NOT: Present omic findings without evidence tier classification MUST NOT: Generate clinical protocols without credentialed reviewer gate MUST NOT: Diagnose or prescribe (decision SUPPORT, not decision MAKING) MUST NOT: Store patient-identifiable genomic data in SHOP projection
Capabilities
INTEL_COMPOSE, PIPELINE_VERSION, SIGNATURE_EVIDENCE, VARIANT_CLASSIFY
COVERAGE: 255/255
SPEC
Purpose
OMICS is the multi-omic intelligence service.
OMICS resurfaces StarGEO’s NIH BD2K-funded crowdsourced gene expression annotation methodology as a governed data pipeline, extends it across five omic layers (genomics, transcriptomics, proteomics, metabolomics, epigenomics), and delivers clinician-ready decision support through governed CHAT channels gated by board-level credentialing.
StarGEO (2015-2023) proved that crowd-curation of open GEO data under FAIR principles produces peer-reviewed disease signatures (Nature Scientific Data 2017, doi:10.1038/sdata.2017.125). OMICS generalizes this methodology from transcriptomics to pan-omics, from crowdsourcing to governed AI reasoning, and from research-only to clinical decision support.
Structure
Root OMICS domains (conceptual sub-scopes, realized as LEARNING/IDF patterns):
SIGNATURES/ — Gene expression signatures from meta-analysis (StarGEO heritage)
VARIANTS/ — Variant interpretation pipeline (ACMG/AMP classification)
PATHWAYS/ — Metabolic pathway analysis (multi-omic integration)
PROTOCOLS/ — Clinician-ready intervention protocols (credential-gated)
Required closure artifacts per scope:
CANON.md, README.md, OMICS.md, VOCAB.md, ROADMAP.md, COVERAGE.md, LEARNING.md.
Learning lane per governed scope:
LEARNING.md at the scope root is terminal and SHALL NOT nest further LEARNING/.
Routes
web_docs: https://hadleylab.org/
web_surface: https://hadleylab.org/SERVICES/OMICS/
web_app: https://hadleylab.org/TALKS/OMICSCHAT/
magic: magic://hadleylab.org/SERVICES/OMICS/
Data Contract
1. Omic analysis results are VAULT-gated by default (PRIVATE, credential-restricted)
2. Every analysis event is ledgered (who, when, dataset, method, result)
3. Public data source references (GEO IDs, ClinVar IDs) surface through SHOP
4. Patient-specific interpretations NEVER surface through SHOP
5. Evidence tiers: GOLD (published meta-analysis), SILVER (single-study validated), BRONZE (computational prediction)
6. Variant classifications MUST include ACMG criteria codes
7. Gene expression signatures MUST cite GEO series IDs
Data Sources
| Source | Type | Endpoint | Proxy | Format |
|---|---|---|---|---|
| NCBI GEO | Gene expression data (2M+ samples) | eutils.ncbi.nlm.nih.gov/entrez/eutils/ | api.canonic.org/omics/ncbi/ | REST/JSON |
| ClinVar | Variant classifications | eutils.ncbi.nlm.nih.gov/entrez/eutils/ | api.canonic.org/omics/ncbi/ | REST/JSON |
| PharmGKB | Pharmacogenomics (drug-gene) | api.pharmgkb.org/v1/data/ | api.canonic.org/omics/pharmgkb/ | REST/JSON |
| COSMIC | Somatic mutations (cancer) | cancer.sanger.ac.uk/cosmic/api/ | — | REST/JSON |
| GTEx | Tissue-specific expression | gtexportal.org/api/v2/ | — | REST/JSON |
| TCGA | Cancer genomics | api.gdc.cancer.gov/ | — | REST/JSON |
| PubMed/PMC | Research corpus | eutils.ncbi.nlm.nih.gov/entrez/eutils/ | api.canonic.org/omics/ncbi/ | REST/JSON |
| ClinicalTrials.gov | Active trials | clinicaltrials.gov/api/v2/studies | — | REST/JSON |
| Disease Ontology (DOID) | Disease taxonomy | disease-ontology.org | — | OBO/JSON |
Ecosystem Connectivity
- Upstream:
SERVICESgovernance contracts,GENOMICS+MEDICINEvertical constraints (canonic-canonic). - CLINICAL plane: patient biomarker data feeds omic analysis (VAULT-gated).
- TALK plane: OMICSCHAT channel delivers decision support conversations.
- LEARNING plane: discovered patterns (signatures, pathways, variant reclassifications) backpropagate.
- LEDGER plane: every analysis event (dataset + method + result) ledgered immutably.
- COIN plane: per-analysis COIN events (work measured and minted).
- AUTH plane: board-level certification required for clinical protocol generation.
- KYC plane: clinician credential verification (board certification + state licensing).
- External: GEO, ClinVar, PharmGKB, COSMIC, GTEx, TCGA, PubMed public APIs.
Pages
| Page | Sections |
|---|---|
| Overview | Purpose, Structure |
| Data | Routes, Data Contract, Data Sources |
| Ecosystem | Ecosystem Connectivity |
Default: Overview.
INTEL
Proxy Architecture
| Component | Implementation | Status |
|---|---|---|
| Proxy endpoint | api.canonic.org/omics/{source}/ | ACTIVE |
| Upstream sources | NCBI (GEO, ClinVar, PubMed), PharmGKB | ACTIVE |
| Ledger store | Cloudflare KV (TALK_KV) — ledger:OMICS:{scope} |
ACTIVE |
| Chain integrity | SHA-256 content hash + prev pointer | ACTIVE |
| Rate limiting | Per-IP, per-source throttling | ACTIVE |
Proxy Routes
| Route | Upstream | Purpose |
|---|---|---|
| /omics/ncbi/* | eutils.ncbi.nlm.nih.gov/entrez/eutils/* | GEO, ClinVar, PubMed queries |
| /omics/pharmgkb/* | api.pharmgkb.org/v1/data/* | Pharmacogenomics lookups |
LEDGER Integration
Every proxy query MUST:
- Append to
ledger:OMICS:{source}viaappendToLedger() - Include upstream source, query parameters, response status
- Backpropagate to LEARNING.md as pattern row
Signal mapping:
NCBI query → OMICS_QUERY (source: ncbi, dataset: geo|clinvar|pubmed)
PharmGKB query → OMICS_QUERY (source: pharmgkb)
Analysis event → OMICS_ANALYSIS (method, dataset, result_hash)
Evidence Tier Classification
| Tier | Criteria | LEDGER Signal |
|---|---|---|
| GOLD | Published meta-analysis, peer-reviewed | EVIDENCE_GOLD |
| SILVER | Single-study validated, replicable | EVIDENCE_SILVER |
| BRONZE | Computational prediction, unvalidated | EVIDENCE_BRONZE |
Data Source Intelligence
| Source | Records | Update Frequency | Access |
|---|---|---|---|
| NCBI GEO | 2M+ samples | Daily | Public API (eutils) |
| ClinVar | 2.5M+ variants | Weekly | Public API (eutils) |
| PharmGKB | 45K+ drug-gene pairs | Monthly | Public API |
| COSMIC | 30M+ somatic mutations | Quarterly | Registered access |
| GTEx | 17K+ tissue samples | Archived | Public API |
Test
| prompt | expect | cross |
|---|---|---|
| What are the evidence tier classifications for omic data? | GOLD,SILVER,BRONZE | CLINICAL |
| What proxy routes does OMICS expose? | /omics/ncbi,/omics/pharmgkb | LEDGER |
| How is query integrity maintained for omic proxy calls? | SHA-256,appendToLedger | LEDGER |
| What upstream data sources are available through OMICS? | NCBI,PharmGKB,ClinVar | |
| How many GEO samples are accessible? | 2M |
| *INTEL | OMICS | MULTI-OMIC INTELLIGENCE* |
LEARNING
Ledger
| Date | Pattern | Source |
|---|---|---|
| 2017 | Crowdsourced GEO annotation produces peer-reviewed disease signatures at scale (48+ diseases) | StarGEO Nature Sci Data 2017 |
| 2017 | Disease Ontology (DOID) is the correct taxonomy anchor for cross-study meta-analysis | StarGEO methodology |
| 2023 | StarGEO archived — methodology proven but codebase (web2py/Django) architecturally dated | StarGEO project lifecycle |
| 2026-02-25 | Diadia Health ($10M VC) validates market for AI clinical reasoning over genetic variants + biomarkers | Competitive intelligence |
| 2026-02-25 | ABOPM credentialing creates regulatory moat unavailable to SaaS-only competitors | ABOPM + CANONIC governance analysis |
| 2026-02-25 | Public databases (ClinVar, GEO, PharmGKB) beat proprietary variant databases on verifiability | Competitive analysis vs Diadia |
| 2026-02-25 | NEW_SCOPE | New governance domain: SERVICES/OMICS |
| 2026-02-25 | Diadia Health CEO (Elena Ikonomovska) connected via Anil Bajnath — competitor → potential partner pivot | iMessage intel via Anil |
| 2026-02-25 | ABOPM as neutral credentialing layer bridges OMICS + Diadia — consumer channel feeds clinical pipeline | Cross-axiomatic analysis |
| 2026-02-25 | “Navigating Challenges and Opportunities in Multi-Omics Integration for Personalized Healthcare” (Biomedicines 2024, 12(7), 1496) — digital twins for longitudinal multi-omics | Anil Bajnath shared post-Zoom |
| 2026-02-25 | PMWC 2026 (Mar 4-6) = face-to-face with Elena + Emre — partnership assessment | Anil introduction via iMessage |
| 2026-02-25 | Digital twins solve longitudinal multi-omics data management — n-of-1 models for individual analysis | Mohr et al. Biomedicines 2024, PMID:39062068 |
| 2026-02-25 | AI health indices personalize beyond population averages — validates per-patient OMICS reasoning | Mohr et al. Biomedicines 2024, PMID:39062068 |
| 2026-02-25 | Blockchain/ledger for omic data security — validates CANONIC LEDGER architecture | Mohr et al. Biomedicines 2024, PMID:39062068 |
| 2026-02-25 | Multi-omics publications doubled 2022→2023 — market timing confirmed | Mohr et al. Biomedicines 2024, PMID:39062068 |
Meta-Patterns
| Date | Pattern | Source |
|---|---|---|
| 2026-02-25 | StarGEO methodology (crowd-annotate → meta-analyze → signature) generalizes from transcriptomics to any omic layer | OMICS SPEC design |
| 2026-02-25 | Credential-gated protocol generation (ABOPM) is the economic moat — not the AI | OMICS competitive positioning |
| 2026-02-25 | LEDGER hash-chaining provides provably transparent reasoning — exceeds “transparent AI” marketing claims | CANONIC governance architecture |
| 2026-02-25 | Competitor-to-partner pivot via ABOPM bridge: Diadia consumer + OMICS clinical = complementary channels, not competing | Cross-axiomatic Anil-Diadia-ABOPM analysis |
Constraints
- MUST log every methodology discovery to this ledger
- MUST cite source of learning
- MUST NOT overwrite — append only
- SHOULD propagate shared patterns to MEDCHAT, MAMMOCHAT, ONCOCHAT
| *LEARNING | OMICS | INTEL governs* |
ROADMAP
VOCAB
| Term | Definition |
|---|---|
| AMP | Association for Molecular Pathology — co-authors ACMG variant classification framework. |
| GEO | Gene Expression Omnibus — NCBI public repository of functional genomics data. |
| OMICS | Governed multi-omic intelligence service. |
INHERITANCE CHAIN
SERVICES
SERVICES compose primitives — INTEL + CHAT + COIN. Every service governed. Every scope discovered.
MUST: Maintain TRIAD integrity (CANON.md + VOCAB.md + README.md)
MUST: Treat SPEC as scope identity (`{SCOPE}` directory), not as a file
MUST: Every SERVICE scope include ROADMAP.md, COVERAGE.md, LEARNING.md, and `{SCOPE}.md` as governed content surfaces
MUST: Discover SERVICE scopes from filesystem only (no manual catalog)
MUST: Keep http:// and magic:// on the same namespace (transport differs, scope path matches)
MUST: CANON.md = axiom + universal constraints (no service names, no paths, no implementation)
MUST: README.md = how to run the CANON (nothing else)
MUST: {SCOPE}.md = SPEC — the interface (purpose, routes, projections, ecosystem)
MUST: SHOP.md = public projection file (per scope, filesystem-discoverable)
MUST: VAULT.md = private projection file (per scope, filesystem-discoverable)
MUST: Runtime implementation remains under ~/.canonic; this workspace is governance-first
MUST NOT: Hardcode service names in CANON constraints (law speaks universals)
MUST NOT: Define ungoverned terms outside VOCAB.md
MUST NOT: Treat `{SCOPE}.md` as SPEC identity
MUST NOT: Move architecture/lifecycle into README
MUST NOT: Leak private projections to public surfaces
MUST NOT: Maintain duplicate mapping tables outside generated manifest outputs
MUST NOT: Add runtime jargon to governance contracts
MUST: Ledger-consuming services declare source ledgers, scope filters, and closure gates
MUST: Learning governance remains live — closure claims require fresh DISCOVER → GENERATE → RELINK evidence
hadleylab-canonic
HADLEYLAB ships software. Every app, book, paper, deal, and patent is PROOF that MAGIC works. COIN = WORK. LEARNING = COMPUTE.
MUST: Every app, book, paper, deal, or patent is evidence of MAGIC MUST: All scopes inherit canonic-canonic/CANONIC.md governance MUST: All users governed under USERS/ via SERVICES/USER MUST: Cross-index INTEL across users (INTEL.md) MUST: Shared events propagate to ALL affected user dashboards MUST: Maintain governance workspace purity (.md files only) MUST: Ledger all COIN (validated work) through MAGIC 255 MUST: Compile all INTEL from governed sources MUST: Keep frontend/runtime implementation under ~/.canonic (hidden runtime) MUST: Surface governed TALK, Library, and SERVICES scopes (no orphan content) MUST: Derive nav labels from governed scope names (no hardcoded strings) MUST NOT: Publish without governance (CANON.md required) MUST NOT: Duplicate primitives — compose from INTEL, CHAT, COIN MUST NOT: Silo intelligence inside a single user when multiple are affected MUST NOT: Expose VAULT contents outside NDA scope MUST NOT: Store runtime artifacts in governance workspace
canonic-canonic
SPEC is governance. `canonic-canonic/` is the spec root.
MUST: Keep this repo governance-only (.md/.pdf) MUST: Publish workspace mapping in CANONIC.git (no hardcoded repo lists) MUST: Preserve three primary lanes: FOUNDATION, INDUSTRIES, MAGIC MUST NOT: Commit runtime artifacts here (runtime belongs in ~/.canonic/) MUST: Sell MAGIC tiers — the product, not the proof (proof is hadleylab-canonic) MUST NOT: Embed beta-test app URLs in platform page content