Placement of TASC

Approved Recommendations

A proposal for format, placement, and communication standards

TASC — February 2026

Why We Need This

The Problem Today

• Outputs scattered across Google Docs, GitHub, emails, meeting notes
• Stakeholders can’t find or reference decisions
• No single source of truth — duplication, version confusion
• Inconsistent formats across authors and time periods
• New members have no way to catch up on past decisions

What We’re Proposing

• A standard format so every TASC output looks and feels consistent
• A clear placement strategy so anyone finds any decision within 30 seconds
• A communication workflow so the GA4GH community knows when something changes

What TASC Has Produced So Far

Recommendations (4)

Governance (1)

5

approved outputs

and growing

Without standards, inconsistency gets worse with every new document.

Three Questions This Proposal Addresses

We propose answers to three distinct concerns:

1

FORMAT

How should we present TASC outputs?

2

PLACEMENT

Where should we put them so they’re findable?

3

COMMUNICATION

How should we tell the GA4GH community?

SECTION 1

FORMAT

How should we present TASC outputs?

The Case for Two Document Types

Why format them differently?

• Policies change over time — they need to be living documents
• Decisions should be immutable — editing erases the original reasoning
• Mixing both in one document buries rationale inside pages of process

How Other Standards Organizations Do This

Every major standards body separates living specs from decision rationale.

Key patterns:

• Separation of concerns — specs vs. decision records are always distinct
• Immutability — decision documents are never retroactively edited
• Our ADR format is closest to W3C TAG Findings

Why ADRs? The Problem They Solve

Our charter already requires them. Step 3.8: “Final decisions will be recorded in an ADR.”

Without ADRs

• Decisions live in meeting minutes nobody re-reads
• “Why four maturity levels?” — nobody remembers, reasoning buried in 2-hour recordings
• Proposals to revisit decisions without knowing what was already rejected

With ADRs

• Every decision: a short, self-contained document (1–2 pages)
• Context captures the problem and alternatives considered
• Consequences make trade-offs explicit
• A new member reads 7 ADRs in 30 min and understands every major decision

When to Use Which? A Proposed Decision Rule

“The policy tells us the process. The ADR records when we actually used that process to make a choice.”

Write a Policy/Guide when:

Defining ongoing rules, procedures, or standards that apply broadly and may evolve

Write an ADR when:

The decision could have gone another way and the rationale matters for future reference

Concrete example:

GA4GH-04 (Policy)

Defines the maturity model framework — the process for how maturity works

ADR-001 (Decision Record)

Records the specific decision to adopt four levels (not three, not five) and documents why

Proposed Standard Metadata Format

Recommendations / Governance

Source: TASC

Recommendation: GA4GH-[NN]

Title: [Full title]

Related GitHub Issues: [#N](url)

Authors: [Name1], [Name2]

Date: YYYY-MM-DD

Status: Approved

ADR Template (Nygard)

# ADR-NNN: [Short Title]

Date: YYYY-MM-DD

Status: Accepted

Deciders: [Who decided]

## Context

## Decision

## Consequences

Proposed Numbering Convention

GA4GH-NN

Recommendations

GOV-NN

Governance documents

ADR-NNN

Decision records

Proposed Document Lifecycle

GitHub Issue

▶

Anyone in GA4GH

community can raise

Discussion

▶

TASC meetings,

async on GitHub/Slack

Draft

▶

Work in progress

in /drafts/

Review / Vote

▶

70% approval

threshold per charter

Approved

Policy → /recommendations/

ADR → /adr/

Gov → /governance/

Final step: Synced to GA4GH website + Airtable. This lifecycle aligns with the charter’s four-step process (Collect → Develop → Vote → Disseminate).

We’re proposing to formalize the output format and placement at the end of that process.

ADR in Practice: What It Looks Like

ADR-001: Adopt Four-Level Maturity Model

Date: 2025-07-18 | Status: Accepted

Deciders: TASC Leadership, CPO, Work Stream Representatives

Context

GA4GH needs to communicate feature stability to adopters. Without a maturity signal, conservative adopters won’t engage.

Alternatives

Three levels (no Trial Use), five levels (added “Experimental”), FHIR’s maturity model directly.

Decision

Four levels — Draft, Trial Use, Normative, Deprecated.

Why not three?

A single “stable” level doesn’t distinguish “ready for testing” from “long-term commitment.”

1 page

captures months of discussion

A new TASC member reads this and immediately understands the decision, the alternatives, and the reasoning.

SECTION 2

PLACEMENT

Where should we put them so they’re findable?

Proposed GitHub Repository Structure

ga4gh/TASC/

├── README.md

├── adr/

│ ├── README.md (index table)

│ ├── template.md

│ ├── 001-adopt-four-level-maturity-model.md

│ ├── 002-require-two-implementations.md

│ └── ... (7 ADRs)

├── governance/

│ └── TASC_Governance_Charter.md

├── recommendations/

│ ├── API pagination guide.md

│ ├── Service Info Type Registry.md

│ └── ... (4 recommendations)

├── drafts/ (work in progress)

└── service-info/

This structure already exists in the repo.

We’re proposing to adopt it as the standard going forward.

GA4GH Website — Cards

All approved outputs should appear as cards on the GA4GH website, linking to GitHub.

Each card would link back to the GitHub source document — the single source of truth.

GA4GH Website — Cards (Current View)

GA4GH Website — Airtable Metadata

Rich metadata with search and filter capabilities, synced from GitHub.

Title

Document name

Description

Brief summary

Alignment Scope

GA4GH alignment area

Work Streams

Affected work streams

Products

Related GA4GH products

Tags

Searchable keywords

Directive (Y/N)

Mandatory vs. Guidance

Link

URL to GitHub source

GA4GH Website — Airtable (Current View)

• Using Airtable (embedded on the TASC webpage)
• Rich metadata (Recommendation/directive metadata )
• Title
• Description
• Alignment Scope
• Work Stream & Groups Impacted
• Products affected
• Additional Tags
• Directive (Y/N)
• Further information
• Search and filter features
• Can automatically be updated from GitHub

SECTION 3

COMMUNICATION

How should we tell the GA4GH community?

Proposed Communication Channels

Proposed Communication Workflow

When a new output is approved:

1

Merge PR

GitHub repo (source of truth)

2

Update Airtable

Metadata (auto or manual)

3

Post

TASC mailing list + Slack #tasc

4

Update Website

GA4GH website cards

5

Present

Next GA4GH Connect if significant

This ensures no approved output “goes dark” — every output reaches the people who need to know.

SECTION 4

WHAT WE’RE ASKING FOR

A summary of where we are and what we need

Current State

What’s Already in Place

• 4 recommendations placed in GitHub repo
• 1 governance charter placed in GitHub repo
• Airtable metadata prepared (5 entries)
• Document formats normalized (consistent frontmatter, TOCs added)

What’s Missing

• Formal TASC approval of format and placement standards
• GA4GH website cards for all approved outputs
• Automated GitHub-to-Airtable sync
• Formalized communication workflow

What We’re Asking TASC to Approve

1

Adopt two document types — Policy/Guide (living) and ADR (immutable)

2

Adopt the proposed metadata template — consistent frontmatter + Nygard ADR template

3

Adopt the numbering convention — GA4GH-NN, GOV-NN, ADR-NNN

4

Adopt the GitHub repo structure — as the canonical placement for all outputs

5

Request GA4GH website updates — cards for all 5 approved outputs

6

Adopt the communication workflow — so every output reaches the right audiences

The overhead is minimal. The structure already exists. The documents are already written. We’re asking to formalize what’s already working and fill the remaining gaps.

VOTE SUMMARY

Placement of TASC Approved Recommendations

• TASC is asked to approve the following six items to formalize format, placement, and communication standards for all TASC outputs.
• PR#76

1

Two Document Types

Policy/Guide (living) + ADR (immutable)

2

Metadata Template

Standard frontmatter + Nygard ADR format

3

Numbering Convention

GA4GH-REC-NN, TASC-GOV-NN, TASC-ADR-NN

4

GitHub Repo Structure

Canonical placement for all outputs

5

Website Cards

GA4GH website cards for all 5 outputs

6

Comms Workflow

Every output reaches the right audience

The overhead is minimal. The structure already exists. The documents are already written. We're asking to formalize what's already working and fill the remaining gaps.

TASC — February 2026

Approval requires 70% vote threshold per charter