|
| 1 | +<!-- ============================================================================ |
| 2 | +AI: Claude Code | Opus 4.8 (1M context) | 2026 June 18 |
| 3 | +Human: Eric Edsinger |
| 4 | +Purpose: Design spec for a new first-class `annogroups` subproject — sequences |
| 5 | + grouped by shared annotation features, per source database, across the |
| 6 | + four canonical annogroup types. Captures the agreed model; gated behind |
| 7 | + user sign-off before any build. |
| 8 | +Scope: The proposed annogroups subproject + the downstream restructuring it |
| 9 | + implies (annotations_X_ocl, integrator). Planning doc in the AI sandbox. |
| 10 | +Status: DRAFT — for sign-off. |
| 11 | +============================================================================ --> |
| 12 | + |
| 13 | +# Design spec — `annogroups` subproject |
| 14 | + |
| 15 | +## 1. Purpose |
| 16 | + |
| 17 | +A new `subprojects/annogroups/` subproject produces **annogroups** as a |
| 18 | +first-class, reusable GIGANTIC product. Downstream subprojects |
| 19 | +(`annotations_X_ocl`, `integrator`, future consumers) consume the **same** |
| 20 | +annogroup IDs from it — one source of truth. This replaces the current |
| 21 | +`single`/`combo`/`zero` scheme (pfam-only, created inside OCL Script 001). |
| 22 | + |
| 23 | +## 2. Canonical definitions |
| 24 | + |
| 25 | +These four are **canonical GIGANTIC terms** — like `phylogenetic_block` or |
| 26 | +`phylogenetic_path`. An **annogroup** is a set of sequences sharing an annotation |
| 27 | +feature pattern, **always in reference to one source** annotation database. Every |
| 28 | +annogroup ID is prefixed `annogroup_<source>_…`. A **feature** is one |
| 29 | +`( source, annotation_identifier )` from the annotations_hmms annotation database. |
| 30 | + |
| 31 | +### `annogroup_feature` |
| 32 | +- **Definition**: sequences that share a single specific feature from the source, |
| 33 | + regardless of what else they carry. A sequence with N features belongs to N |
| 34 | + feature-annogroups (multi-membership). |
| 35 | +- **Identifier**: `annogroup_<source>_<annotation_identifier>` |
| 36 | + e.g. `annogroup_pfam_PF00001`, `annogroup_tmbed_TM`. |
| 37 | + |
| 38 | +### `annogroup_combination` |
| 39 | +- **Definition**: sequences that share the same **unordered, distinct set** of |
| 40 | + source features (copies ignored). |
| 41 | +- **Identifier**: `annogroup_<source>_combination<NNNNN>` (zero-padded counter). |
| 42 | + Map: ID → the feature set, listed **alphabetically**. |
| 43 | + e.g. `annogroup_superfamilies_combination00010 → SSF00010,SSF00055`. |
| 44 | + |
| 45 | +### `annogroup_architecture` |
| 46 | +- **Definition**: sequences that share the same **ordered arrangement** of |
| 47 | + positional source features (N→C by start coordinate, copies kept). |
| 48 | +- **Identifier**: `annogroup_<source>_architecture<NNNNN>` (zero-padded counter). |
| 49 | + Map: ID → the ordered feature list **with coordinates**. |
| 50 | + e.g. `annogroup_pfam_architecture00001 → |
| 51 | + PF00001_start10_stop50,PF00001_start100_stop150,PF00011_start200_stop250`. |
| 52 | + |
| 53 | +### `annogroup_absent` |
| 54 | +- **Definition**: sequences (across the species-set proteomes) that have **no** |
| 55 | + feature from the source. |
| 56 | +- **Identifier**: `annogroup_<source>_absent` e.g. `annogroup_pfam_absent`. |
| 57 | + |
| 58 | +Counters (`combination`/`architecture`) are scoped per (source, type), zero-padded, |
| 59 | +and assigned **deterministically** (sort canonical keys, then number) so the same |
| 60 | +input always yields the same IDs. `feature` and `absent` need no map; their IDs |
| 61 | +are self-describing. |
| 62 | + |
| 63 | +## 3. Worked example |
| 64 | + |
| 65 | +A protein with `PF00001@10-50, PF00001@100-150, PF00011@200-250`: |
| 66 | + |
| 67 | +| Type | This protein belongs to | |
| 68 | +|---|---| |
| 69 | +| feature | `annogroup_pfam_PF00001` **and** `annogroup_pfam_PF00011` | |
| 70 | +| combination | the group keyed by `{PF00001, PF00011}` (alphabetical, deduped) | |
| 71 | +| architecture | the group keyed by `PF00001_start10_stop50,PF00001_start100_stop150,PF00011_start200_stop250` (N→C order) | |
| 72 | +| absent | not absent for pfam (it has pfam features) | |
| 73 | + |
| 74 | +## 4. How many types a source yields is **data-determined** (not a user option) |
| 75 | + |
| 76 | +A source produces 3 or 4 of the canonical types depending on the kind of data its |
| 77 | +tool emits — never a user knob: |
| 78 | + |
| 79 | +- **Positional, multi-feature** sources (pfam, gene3d, smart, cdd, superfamily, |
| 80 | + tmbed segments, metapredict regions, …) → all **4** types. |
| 81 | +- **Whole-protein / presence** sources (deeploc localization) → **3** (feature, |
| 82 | + combination, absent); architecture is undefined for position-less features |
| 83 | + and is simply not produced. |
| 84 | + |
| 85 | +Each source's parser also decides its **feature granularity**, e.g.: |
| 86 | +- `tmbed`: `has-TM` at the feature level, with combination/architecture built from |
| 87 | + the per-segment data in the annotation DB. |
| 88 | +- `metapredict`: `has-IDR` at the feature level, with combination/architecture |
| 89 | + built from the per-region data in the annotation DB. |
| 90 | + |
| 91 | +## 5. Membership universe & `absent` |
| 92 | + |
| 93 | +Per-sequence absence is trivial (did the source annotate this sequence?). The |
| 94 | +**proteome matters only for completeness of enumeration**: to list every member |
| 95 | +of any annogroup (incl. `absent`), the source must have run over the **entire** |
| 96 | +species-set proteome set. |
| 97 | + |
| 98 | +- **Universe** = all sequences in the species-set proteomes. |
| 99 | +- `annogroup_<S>_absent` = universe − (sequences with ≥1 S-feature). |
| 100 | + |
| 101 | +The proteome sequence lists are read from upstream **`output_to_input/`** — |
| 102 | +`genomesDB/output_to_input/STEP_4-create_final_species_set/` — per GIGANTIC |
| 103 | +convention that all inter-subproject data flows through `output_to_input/` |
| 104 | +(§2; no other path is allowed). |
| 105 | + |
| 106 | +## 6. Modularity — one parser per source |
| 107 | + |
| 108 | +- A **common framework/driver** reads the YAML, inspects the annotation DB for |
| 109 | + available sources, dispatches to per-source parsers, then builds the canonical |
| 110 | + types + maps + membership uniformly and writes outputs. |
| 111 | +- **One Python parser per source database**. Each parser owns its source's feature |
| 112 | + semantics and returns a normalized per-sequence feature list |
| 113 | + `sequence_id → [ ( accession, start, stop, is_positional ), … ]`; the framework |
| 114 | + does everything else identically. **New source = new parser**, nothing else |
| 115 | + changes. |
| 116 | + |
| 117 | +## 7. Configuration (`START_HERE-user_config.yaml`) |
| 118 | + |
| 119 | +- `species_set` (e.g. species70) — drives the proteome universe. |
| 120 | +- `sources:` — `all` (every source present in the annotation DB) **or** an explicit |
| 121 | + subset; the subproject inspects the DB and validates the request. |
| 122 | +- (No annogroup-type knob — type count is data-determined per §4.) |
| 123 | + |
| 124 | +## 8. Inputs / outputs (all via `output_to_input/`, §2) |
| 125 | + |
| 126 | +**Inputs** |
| 127 | +- `annotations_hmms/output_to_input/BLOCK_build_annotation_database/` — |
| 128 | + standardized feature rows per source (`Sequence_Identifier, Database_Name, |
| 129 | + Annotation_Identifier, Domain_Start, Domain_Stop`). |
| 130 | +- `genomesDB/output_to_input/STEP_4-create_final_species_set/` — proteome |
| 131 | + sequence lists (the universe). |
| 132 | + |
| 133 | +**Outputs** (`annogroups/output_to_input/`), per source — |
| 134 | +- annogroup **membership** (sequence → annogroup, all produced types), |
| 135 | +- annogroup **map** (combination/architecture ID → feature set/list + type + counts), |
| 136 | +- a **manifest** of sources + types produced. |
| 137 | + |
| 138 | +Available sources in the live DB (2026-06): cdd, deeploc, funfam, gene3d, go, |
| 139 | +interproscan, metapredict, ncbifam, panther, pfam, prints, sfld, smart, |
| 140 | +superfamily, tmbed (+ signalp where present). |
| 141 | + |
| 142 | +## 9. Downstream restructuring (breaking — accepted, "worth the effort") |
| 143 | + |
| 144 | +- **`annotations_X_ocl`**: Script 001 stops *creating* annogroups and instead |
| 145 | + *loads* them from `annogroups/output_to_input/`; OCL runs per annogroup as today. |
| 146 | + ⚠️ Four types × many sources ≫ today's pfam single+combo (~74k); OCL scale and |
| 147 | + the `path_states` matrices grow a lot — **estimate volume before a full re-run**. |
| 148 | +- **`integrator/BLOCK_annotations_X_orthogroups`**: consumes annogroup membership |
| 149 | + from `annogroups/` instead of from `annotations_X_ocl`; its single+combo logic |
| 150 | + generalizes to the canonical types. |
| 151 | + |
| 152 | +## 10. GIGANTIC conventions |
| 153 | + |
| 154 | +New `subprojects/annogroups/` as a BLOCK-type subproject (§41: |
| 155 | +`BLOCK_build_annogroups`, framework driver + per-source parser scripts under |
| 156 | +`ai/scripts/`). NextFlow workflow (per-source fan-out), unified `RUN-workflow.sh` |
| 157 | +(§29), `START_HERE-user_config.yaml`, fail-fast (§36), `write_run_log` (§45), |
| 158 | +`output_to_input/` (§2) + `upload_to_server/` (§38), full doc set (§3, §42, §48, |
| 159 | +§56), per-BLOCK conda env (§28), self-documenting TSV headers (§34). |
| 160 | + |
| 161 | +## 11. Build phases (after sign-off) |
| 162 | + |
| 163 | +1. Scaffold `subprojects/annogroups/` + framework driver + the **pfam** parser; |
| 164 | + validate the four canonical types end-to-end on one source. |
| 165 | +2. Add remaining per-source parsers (positional + whole-protein cases). |
| 166 | +3. Wire `output_to_input/`; estimate full-source volume. |
| 167 | +4. Restructure `annotations_X_ocl` Script 001 to consume annogroups. |
| 168 | +5. Restructure the integrator to consume annogroups. |
| 169 | +6. Re-run + re-publish the chain; update docs across all three subprojects. |
0 commit comments