Add TASC repository structure with recommendations, ADRs, and governance documentation

.gitignore

@@ -0,0 +1 @@
+data

README.md

@@ -8,11 +8,39 @@ While TASC functions as a central decision-making body, all of its decisions are
 
 TASC organizes and monitors its technical alignment activities through a [GitHub Project board](https://github.com/orgs/ga4gh/projects/9/views/1), where you can find and track the progress of current issues and initiatives.
 
+## Repository Structure
+
+This repository is organized into the following directories:
+
+```
+/
+├── README.md (overview & quick reference)
+├── /adr/ (Architectural Decision Records)
+├── /governance/ (TASC operating charter)
+├── /recommendations/ (TASC outputs)
+├── /drafts/ (work in progress)
+└── /service-info/ (service type registry)
+```
+
+### Directory Descriptions
+
+- **`/adr/`** - Architectural Decision Records documenting key technical decisions made by TASC. Each ADR captures what was decided, why, and the consequences. ADRs are immutable historical records. See [adr/README.md](adr/README.md) for the complete index.
+
+- **`/governance/`** - TASC's governance charter defining how TASC operates, including membership, meeting format, and decision-making processes.
+
+- **`/recommendations/`** - Approved TASC recommendations and policy documents that provide guidance to GA4GH work streams. These include API standards, process guidelines, and technical specifications.
+
+- **`/drafts/`** - Work-in-progress documents under development. Documents move from drafts to recommendations upon approval.
+
+- **`/service-info/`** - The GA4GH Service Info Type Registry, which maintains standardized service type identifiers for GA4GH API servers enabling service discovery.
+
 ## Table of Contents
+
+- [Repository Structure](#repository-structure)
 - [TASC Structure](#tasc-structure)
-- [TASC Members](#tasc-members)   
+- [TASC Members](#tasc-members)
 - [Group Meeting Format](#group-meeting-format)
-- [Decision-Making Process](#decision-making-process)   
+- [Decision-Making Process](#decision-making-process)
 - [Issue labels](#issue-labels)   
 
 ## TASC Structure
@@ -159,7 +187,7 @@ For asynchronous discussion, members use:
 6. If approval not reached through multiple rounds, TASC Leadership makes final decision
 7. Leadership can take decisions if two consecutive meetings are not quorate
 8. Proposals open for more than 12 months must be taken to vote
-9. Final decisions recorded in [Architectural Decision Records](https://adr.github.io/)
+9. Final decisions recorded in [Architectural Decision Records](adr/)
 10. CPO may reopen issues or review decisions in consultation with PSC, TASC, SLC, or GA4GH Executive Committee
 
 ### **Step 4: Dissemination**

adr/001-adopt-four-level-maturity-model.md

@@ -0,0 +1,110 @@
+# ADR-001: Adopt Four-Level Maturity Model for GA4GH Technical Specifications
+
+**Date:** 2025-07-18 | **Status:** Accepted
+
+**Deciders:** TASC Leadership, CPO, Work Stream Representatives
+
+---
+
+## Context
+
+GA4GH develops data exchange standards for federated genomic data sharing. New technical specifications (like VRS) must be developed and iterated through community implementations.
+
+**The Problem:**
+- Standards need **stability** for initial community adoption
+- Standards need to **evolve** with minimal disruption
+- Adopters exist across entire Innovation Adoption Lifecycle (innovators → early adopters → majority → laggards)
+- Without maturity communication, conservative adopters won't engage; early adopters waste effort on unstable features
+
+**Alternatives Considered:**
+
+1. **No Maturity Model**
+   - ❌ All features appear equally stable
+   - ❌ Conservative adopters wait indefinitely
+   - ❌ No signal for safe vs experimental
+
+2. **Binary (Experimental/Stable)**
+   - ✅ Simple
+   - ❌ No middle ground for testing
+   - ❌ Doesn't show validation level
+
+3. **Three-Level (Draft/Stable/Deprecated)**
+   - ✅ Shows progression
+   - ❌ Gap too large between Draft and Stable
+   - ❌ No distinction between "testing" and "production"
+
+4. **FHIR-style (5+ levels)**
+   - ✅ Very granular
+   - ❌ Too complex for GA4GH
+   - ❌ Hard to define criteria
+
+5. **Four-Level (Draft/Trial Use/Normative/Deprecated)** ✓
+   - ✅ Clear progression
+   - ✅ "Trial Use" provides testing middle ground
+   - ✅ Proven in HL7 FHIR
+   - ✅ Manageable complexity
+
+---
+
+## Decision
+
+Adopt **four-level maturity model** for GA4GH technical specification features:
+
+| Level | Description | Target Adopters | Stability |
+|-------|-------------|-----------------|-----------|
+| **Draft** | Requirements gathered, documented | Innovators only | Unstable, frequent changes |
+| **Trial Use** | Community-reviewed, ready for testing | Early Adopters | Changes with consultation |
+| **Normative** | Proven stable, long-term support | Majority | No breaking changes in major version |
+| **Deprecated** | Being phased out | (Migration) | Removal in next version |
+
+**Scope:** Data classes, properties, protocols (not docs/tests)
+
+**Advancement:** Requires defined criteria, community ballot, decision-maker consensus
+
+**Inheritance:** Child classes ≤ parent maturity; properties ≤ class maturity
+
+---
+
+## Consequences
+
+### Positive
+
+   - ✅ Serves entire adoption lifecycle (innovators can experiment, conservative can wait for Normative)
+   - ✅ Explicit stability commitments per level 
+   - ✅ Reduces wasted implementation effort
+   - ✅ Enables continuous evolution without destabilizing mature components
+   - ✅ Aligns with proven HL7 FHIR precedent
+
+### Negative
+
+   - ❌ Annotation overhead (JSON Schema maturity properties)
+   - ❌ Advancement process complexity (ballots, tracking)
+   - ❌ Slower progression to Normative status
+   - ❌ Learning curve for community
+   - ❌ More frequent version releases
+
+### Risks & Mitigations
+
+**Risk:** Features stall at Trial Use indefinitely
+- **Mitigation:** 12-month maximum, must vote or close
+
+**Risk:** Inconsistent annotations across specs
+- **Mitigation:** TASC oversight, templates
+
+**Risk:** Conservative adopters avoid Trial Use
+- **Mitigation:** Clear stability commitment docs
+
+---
+
+## References
+
+- **Full Policy:** [TASC Technical Specification Maintenance](../recommendations/TASC%20Technical%20Specification%20Maintenance.md#feature-maturity-levels)
+- **Examples:**
+  - [VRS Allele maturity annotation](https://github.com/ga4gh/vrs/blob/454c5312e8e425eb170901c7520311f3ca7904e3/schema/vrs/json/Allele#L6)
+  - [VA-Spec property-level maturity](https://github.com/ga4gh/va-spec/blob/4c14e9f7f033dce3b6701ecd0fccca415476fd76/schema/va-spec/profiles/caf/json/CohortAlleleFrequency#L142-L143)
+
+---
+
+## Notes
+
+The "Trial Use" level is critical - it provides middle ground where features have community validation but aren't yet committed to long-term API stability. This reflects the Innovation Adoption Lifecycle model and different implementer risk tolerances.

adr/002-require-two-implementations-trial-use.md

@@ -0,0 +1,97 @@
+# ADR-002: Require Two Implementations for Trial Use Advancement
+
+**Date:** 2025-07-18 | **Status:** Accepted
+
+**Deciders:** TASC Leadership, CPO, Work Stream Representatives
+
+---
+
+## Context
+
+Draft features need validation before wider community adoption. The question is: how much validation is enough to advance to Trial Use?
+
+**The Problem:**
+- Need evidence that Draft features work before promoting to Trial Use
+- Want diverse perspectives (avoid single-vendor lock-in)
+- Must balance validation rigor vs speed of adoption
+- Need to ensure open-source availability
+
+**Alternatives Considered:**
+
+1. **One Implementation**
+   - ✅ Faster advancement
+   - ❌ No evidence of interoperability
+   - ❌ Single vendor perspective
+
+2. **Three+ Implementations**
+   - ✅ Strong validation
+   - ❌ Too slow for Trial Use (this is Normative criteria)
+   - ❌ May never reach threshold
+
+3. **Two Implementations (1 open)** ✓
+   - ✅ Evidence of interoperability
+   - ✅ Multiple perspectives
+   - ✅ Open source ensures transparency
+   - ✅ Reasonable bar for Trial Use
+
+4. **No Requirement**
+   - ❌ No validation before testing
+   - ❌ Wastes community effort
+
+---
+
+## Decision
+
+**Draft → Trial Use requires:**
+- Minimum **2 independent implementations**
+- At least **1 must be open source**
+- Implementers must **commit to supporting** the feature once advanced
+
+**Rationale:**
+- Two implementations prove basic interoperability
+- Open source requirement ensures transparency and community access
+- Aligns with GA4GH Product Development 14.8.3 (implementations requirement)
+
+---
+
+## Consequences
+
+### Positive
+
+✅ Validates features work before wider testing  
+✅ Ensures interoperability between independent implementations  
+✅ Open source requirement prevents vendor lock-in  
+✅ Reasonable bar (not too high/low)  
+✅ Builds early adopter community  
+
+### Negative
+
+❌ Slows advancement (must find 2 implementers)  
+❌ Small work streams may struggle to find implementers  
+❌ Requires tracking of implementers and commitments  
+❌ Risk of "friendly" implementations (same team)  
+
+### Risks & Mitigations
+
+**Risk:** Can't find 2 implementers for niche features
+- **Mitigation:** Feature may not warrant Trial Use; keep as Draft or close
+
+**Risk:** "Paper implementations" (same team, different repos)
+- **Mitigation:** Require "independent" implementers, review in ballot
+
+**Risk:** Open source implementation is abandoned
+- **Mitigation:** Maturity can be downgraded if support ends
+
+---
+
+## References
+
+- **Full Policy:** [TASC Technical Specification Maintenance](../recommendations/TASC%20Technical%20Specification%20Maintenance.md#advancing-from-draft-to-trial-use)
+- **GA4GH Process:** [Product Development 14.8.3](https://www.ga4gh.org/our-products/development-and-approval-process/#section_5)
+- **Related ADR:** [ADR-001: Four-Level Maturity Model](001-adopt-four-level-maturity-model.md)
+
+---
+
+## Notes
+
+This requirement applies only to Draft → Trial Use. Normative requires additional implementations beyond these initial two, demonstrating broader interoperability. The "independent" requirement means different organizations, not just different repositories.

adr/003-constrain-child-class-maturity.md

@@ -0,0 +1,114 @@
+# ADR-003: Constrain Child Class Maturity to Parent Class Maturity
+
+**Date:** 2025-07-18 | **Status:** Accepted
+
+**Deciders:** TASC Leadership, CPO, Work Stream Representatives
+
+---
+
+## Context
+
+GA4GH data models use inheritance (e.g., VRS Entity class inherited by Allele, Haplotype). Need rules for how maturity applies to inheritance hierarchies.
+
+**The Problem:**
+- Parent classes have shared properties inherited by children
+- If child is Normative but parent is Draft, which properties are stable?
+- Could a less mature child artificially appear stable through inheritance?
+
+**Example:**
+```
+Entity (parent, Draft)
+  ├─ id: string
+  ├─ label: string
+  └─ Allele (child, ???)
+      └─ state: string
+```
+
+**Alternatives Considered:**
+
+1. **Independent Maturity**
+   - ✅ Maximum flexibility
+   - ❌ Confusing stability (which properties are stable?)
+   - ❌ Allele could be "Normative" but inherit unstable properties
+
+2. **Child ≤ Parent** ✓
+   - ✅ Clear: child can't exceed parent
+   - ✅ Forces upstream stabilization first
+   - ✅ No false stability signals
+   - ✅ Allows extending mature parents with Draft properties
+
+3. **Child = Parent**
+   - ✅ Always consistent
+   - ❌ Too restrictive (can't add new properties)
+   - ❌ Prevents experimentation on mature classes
+
+4. **Property-Level Only**
+   - ✅ Very granular
+   - ❌ Complex to track
+   - ❌ Doesn't address inherited properties
+
+---
+
+## Decision
+
+**Inheritance Maturity Rules:**
+1. **Child classes ≤ parent class maturity**
+   - Allele (child) cannot be Normative if Entity (parent) is Trial Use
+2. **Properties ≤ containing class maturity**
+   - Draft property cannot exist in Normative class
+
+**Rationale:**
+- Ensures attention to upstream classes first
+- Prevents false stability signals
+- Allows extending mature classes with new Draft properties
+
+**Example:**
+```
+Entity (Normative)        ← Must be stable first
+  ├─ id: string (Normative)
+  ├─ label: string (Normative)
+  └─ Allele (Trial Use)   ← Can be less mature
+      ├─ state: string (Trial Use)
+      └─ newProp: string (Draft)  ← Can add Draft props
+```
+
+---
+
+## Consequences
+
+### Positive
+
+✅ Clear, enforceable rules  
+✅ No false stability signals  
+✅ Forces bottom-up stabilization (parent → child)  
+✅ Still allows experimentation (new properties at lower maturity)  
+✅ Implementers know exactly what's stable  
+
+### Negative
+
+❌ Can't stabilize child without stabilizing parent first  
+❌ May slow advancement if parent isn't ready  
+❌ Requires tracking entire inheritance tree  
+❌ More complex validation rules  
+
+### Risks & Mitigations
+
+**Risk:** Parent class blocks child advancement
+- **Mitigation:** Prioritize parent stabilization; may indicate parent needs work
+
+**Risk:** Confusion about which properties are stable
+- **Mitigation:** Annotate each property with maturity in JSON Schema
+
+---
+
+## References
+
+- **Full Policy:** [TASC Technical Specification Maintenance](../recommendations/TASC%20Technical%20Specification%20Maintenance.md#data-class-inheritance-and-property-maturity)
+- **Example:** [GKS Common Library Entity class](https://github.com/ga4gh/gks-common/blob/1b7e52d6013c6785300aa933efa9210e2aafa57b/schema/gks.common-source.yaml#L7-L31)
+- **Related ADR:** [ADR-001: Four-Level Maturity Model](001-adopt-four-level-maturity-model.md)
+
+---
+
+## Notes
+
+This rule ensures that when an implementer sees "Normative", they can trust ALL inherited properties are also Normative. It prevents situations where a class appears stable but inherits unstable properties from a Draft parent.