eduKateSG · Why Science?
Find the right workflow version, inspect its descriptors and containers, and carry an immutable reference into analysis
Choose the closest route, then return to the full index whenever you need the wider evidence chain.
Science learning becomes powerful when students can tell a measured pattern from a model, a statistical decision from a mechanism, and a useful lead from a finished conclusion. The GA4GH Tool Registry Service, or TRS, is a common API for listing, searching and retrieving descriptions of tools and workflows across registries. GA4GH lists TRS as current, Support Ready and at approved product version 2.0; the official documentation recommends TRS v2 over v1. Registries can expose tool classes, versions, descriptor types and files, container images and verification information. TRS improves discovery and exchange, but registry presence is not proof of scientific quality, security, reproducibility, licensing suitability or compatibility with every execution engine. This guide supports Primary Science, PSLE Science, Secondary Science, O-Level Science and STEM education as a longform evidence-reading route; it is not medical advice, a laboratory protocol, an admission promise or a career guarantee.
Related eduKate reading: GA4GH Data Repository Service and portable access; refget and globally identifiable reference sequences; Crypt4GH and encrypted genomic files; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH Tool Registry Service product page, current TRS v2.0; Official GA4GH TRS v2 documentation; Official GA4GH TRS specification repository; Official GA4GH TRS validator; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Standards, service interfaces and recommendations can change, so preserve the dated documentation and versions used.
A deeper reading route
TRS solves a catalogue problem, not a trust problem. Without a common interface, every workflow registry can describe tools differently, making discovery and exchange harder. With TRS, clients can ask familiar questions about records, versions, descriptors, files and images. Yet a common answer shape cannot guarantee that the underlying workflow is scientifically appropriate, securely packaged or legally reusable. The API makes comparison possible; people and validation systems still decide what the comparison means.
Version identity is the heart of a reproducible selection. A project name can persist for years while commands, defaults, reference assets and container images change. Even a version label can be ambiguous if a registry record is updated in place or a container tag moves. A careful selection report therefore keeps the registry endpoint, tool ID, version ID, descriptor bytes, secondary files and container digests together. Each part answers a different version question.
Verification deserves equally careful reading. A green result may mean that an API response conformed to a schema, that a workflow parsed successfully, that a small fixture completed, or that a scientific benchmark met a defined expectation. Those are valuable but different claims. TRS v2 can carry multiple verification sources, which is a strength when the report preserves who tested what, when, against which version and with which outcome.
Registries are also part of the software supply chain. Descriptors can import other files; containers can include vulnerable dependencies; links can redirect; licences can differ across code, image and reference data. A secure adoption workflow downloads every file, computes digests, checks licences, scans images and runs in a constrained environment before controlled data are introduced. Discovery should accelerate that review, not bypass it.
For students, the catalogue analogy is friendly: finding an experiment card is different from checking its edition, safety notes and evidence. For researchers, TRS offers the same discipline at global scale. The happy goal is a workflow that is easy to find, exact to cite, safe to inspect and honest about what has—and has not—been verified. A classroom can extend the analogy by placing two editions of one card side by side, marking every changed material, step and expected observation. That small exercise shows why a familiar title cannot substitute for a version record. It also makes a subtle computing idea visible: two entries can be related without being identical, and identity can be tested at the level of metadata, files or content digests. The same layers protect real analyses from accidental substitution.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Discover | Which tool or workflow matches the intended analysis? | Search results, classes, names and organisation metadata | A candidate identifier |
| Resolve | Which exact version and descriptor should be used? | Version IDs, descriptor types and files | An immutable workflow reference |
| Inspect | Which containers, authors and verification records travel with it? | Images, checksums, authors and verification sources | A reviewable execution package |
| Validate | Can it run safely and answer the question? | Validator results, tests, licences and scientific evidence | A qualified candidate, not blind trust |
Inside this guide
1–12 · Foundations and design
- 1. Start with discovery, not trust
- 2. Understand the current product
- 3. Keep the API read-only boundary clear
- 4. Distinguish tools and workflows
- 5. Use stable tool identifiers
- 6. Search with scientific intent
- 7. Read organisation and author metadata
- 8. Inspect version lists
- 9. Read descriptor types
- 10. Retrieve descriptor files
- 11. Respect descriptor URLs
- 12. Inspect container images
13–24 · Models and estimation
- 13. Read image metadata carefully
- 14. Use verification records as evidence
- 15. Keep verification time-bounded
- 16. Validate with the official tooling
- 17. Inspect service info
- 18. Handle pagination and limits
- 19. Treat missing records cautiously
- 20. Review licences before reuse
- 21. Review security before execution
- 22. Review scientific validity
- 23. Connect TRS to WES
- 24. Connect TRS to TES
25–36 · Diagnostics and interpretation
- 25. Connect TRS to DRS
- 26. Support reproducible citation
- 27. Compare registries carefully
- 28. Connect to Primary Science
- 29. Connect to Secondary Science
- 30. Connect to mathematics
- 31. Connect to computing
- 32. Connect to pathways
- 33. Did you know?
- 34. Write a reader-ready selection report
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with discovery, not trust
A registry helps locate a tool or workflow, but discovery is only the beginning of scientific and security review. Popularity and presence do not prove fitness.
Working checkpoint — Tool Registry Service: Write the intended analysis, inputs and required evidence before searching. Keep the registry endpoint, service-info, tool and version IDs, descriptor files, image digests and verification sources together.
For a classroom model, compare fictional experiment-card editions rather than executable software.
Section 2 of 36
2. Understand the current product
GA4GH lists TRS as current, Support Ready and at v2.0, while the documentation explains that v2 supersedes the initial v1 schema.
Working checkpoint — tool identifier: Record the TRS API version and registry implementation version. Read every badge beside its verification source, date, scope, fixture and result.
For future study, connect registries to biology, software engineering and cybersecurity while checking official pathways separately.
Section 3 of 36
3. Keep the API read-only boundary clear
The common TRS model focuses on listing and describing available tools; registries can use different registration and security processes behind that interface.
Working checkpoint — workflow version: Do not assume the discovery API is an upload or approval workflow. Preserve rejected candidates and version differences; a chosen workflow is not the complete selection process.
For scientific writing, cite the TRS endpoint, tool ID, version and digests.
Section 4 of 36
4. Distinguish tools and workflows
A standalone tool performs one bounded operation, while a workflow coordinates multiple steps that may branch and converge. Registries can describe both.
Working checkpoint — descriptor type: Read the tool class before selecting an execution strategy. Separate registry discovery and API conformance from scientific validation, licensing and security approval.
For students, ask whether two catalogue entries share a name, a version or identical bytes.
Section 5 of 36
5. Use stable tool identifiers
A tool ID should identify the registry record, while versions identify evolving releases. Display names can be ambiguous or change.
Working checkpoint — container image: Store registry endpoint, tool ID and version ID together. Treat descriptor and container digests as scientific identifiers: a silent update can change the executed method.
For parents, ask which checks confirm that a discovered workflow is safe and suitable.
Section 6 of 36
6. Search with scientific intent
Keywords such as “variant calling” can return methods with different inputs, organisms, assumptions and evidence.
Working checkpoint — verification source: Filter by data type, workflow language and validated use case. Keep the registry endpoint, service-info, tool and version IDs, descriptor files, image digests and verification sources together.
For a classroom model, compare fictional experiment-card editions rather than executable software.
Section 7 of 36
7. Read organisation and author metadata
Authorship and organisation fields help establish provenance and responsibility but do not independently verify every descriptor or container.
Working checkpoint — Tool Registry Service: Cross-check the project’s official repository and publication. Read every badge beside its verification source, date, scope, fixture and result.
For future study, connect registries to biology, software engineering and cybersecurity while checking official pathways separately.
Section 8 of 36
8. Inspect version lists
A tool can expose multiple versions, each with different descriptors, images and verification status. “Latest” is a moving label.
Working checkpoint — tool identifier: Select an explicit version and preserve its retrieval date. Preserve rejected candidates and version differences; a chosen workflow is not the complete selection process.
For scientific writing, cite the TRS endpoint, tool ID, version and digests.
Section 9 of 36
9. Read descriptor types
TRS v2 supports workflow descriptor types such as CWL, WDL, Nextflow, Galaxy and others exposed by the service. A registry need not support every type.
Working checkpoint — workflow version: Choose a descriptor compatible with the intended engine. Separate registry discovery and API conformance from scientific validation, licensing and security approval.
For students, ask whether two catalogue entries share a name, a version or identical bytes.
Section 10 of 36
10. Retrieve descriptor files
A main descriptor may reference secondary files, imports, configuration or schemas. One file alone may not reproduce the workflow.
Working checkpoint — descriptor type: Fetch the complete file set and build a manifest. Treat descriptor and container digests as scientific identifiers: a silent update can change the executed method.
For parents, ask which checks confirm that a discovered workflow is safe and suitable.
Section 11 of 36
11. Respect descriptor URLs
A descriptor response may provide content directly or through a URL. Redirects and mutable hosting can change what is retrieved later.
Working checkpoint — container image: Download once, verify content and store a digest. Keep the registry endpoint, service-info, tool and version IDs, descriptor files, image digests and verification sources together.
For a classroom model, compare fictional experiment-card editions rather than executable software.
Section 12 of 36
12. Inspect container images
Container images package software dependencies, but a mutable tag such as latest can silently change. Images can also contain vulnerabilities.
Working checkpoint — verification source: Resolve images to immutable digests and scan before execution. Read every badge beside its verification source, date, scope, fixture and result.
For future study, connect registries to biology, software engineering and cybersecurity while checking official pathways separately.
Section 13 of 36
13. Read image metadata carefully
Multiple images or formats may be listed for one version. Compatibility depends on architecture, runtime and command expectations.
Working checkpoint — Tool Registry Service: Test the exact image on the target execution platform. Preserve rejected candidates and version differences; a chosen workflow is not the complete selection process.
For scientific writing, cite the TRS endpoint, tool ID, version and digests.
Section 14 of 36
14. Use verification records as evidence
A version can include verification sources showing that someone tested it. The source, type and outcome define what the record actually supports.
Working checkpoint — tool identifier: Read the verification details instead of displaying a generic badge. Separate registry discovery and API conformance from scientific validation, licensing and security approval.
For students, ask whether two catalogue entries share a name, a version or identical bytes.
Section 15 of 36
15. Keep verification time-bounded
A successful test can become stale when dependencies, registries or external reference data change.
Working checkpoint — workflow version: Record verification date and rerun critical fixtures. Treat descriptor and container digests as scientific identifiers: a silent update can change the executed method.
For parents, ask which checks confirm that a discovered workflow is safe and suitable.
Section 16 of 36
16. Validate with the official tooling
The GA4GH TRS validator can test conformance of known services, but API conformance is different from scientific validation of every registered workflow.
Working checkpoint — descriptor type: Separate service-contract tests from workflow-result tests. Keep the registry endpoint, service-info, tool and version IDs, descriptor files, image digests and verification sources together.
For a classroom model, compare fictional experiment-card editions rather than executable software.
Section 17 of 36
17. Inspect service info
Modern TRS implementations expose GA4GH service information rather than the older metadata endpoint. This helps clients identify service type and version.
Working checkpoint — container image: Save service-info beside registry responses. Read every badge beside its verification source, date, scope, fixture and result.
For future study, connect registries to biology, software engineering and cybersecurity while checking official pathways separately.
Section 18 of 36
18. Handle pagination and limits
Registry search and list endpoints can paginate results. A first page is not the complete catalogue, and ranking can vary.
Working checkpoint — verification source: Traverse pages systematically and preserve query parameters. Preserve rejected candidates and version differences; a chosen workflow is not the complete selection process.
For scientific writing, cite the TRS endpoint, tool ID, version and digests.
Section 19 of 36
19. Treat missing records cautiously
A tool missing from one registry may exist elsewhere or under another identifier. Non-discovery is not evidence that a method does not exist.
Working checkpoint — Tool Registry Service: Search other trusted registries and project repositories. Separate registry discovery and API conformance from scientific validation, licensing and security approval.
For students, ask whether two catalogue entries share a name, a version or identical bytes.
Section 20 of 36
20. Review licences before reuse
Open discovery does not mean every tool, container or reference asset permits every use.
Working checkpoint — tool identifier: Capture software, container and data licences separately. Treat descriptor and container digests as scientific identifiers: a silent update can change the executed method.
For parents, ask which checks confirm that a discovered workflow is safe and suitable.
Section 21 of 36
21. Review security before execution
Descriptors and containers are executable supply-chain inputs. A registry record can be compromised, outdated or malicious.
Working checkpoint — workflow version: Use allowlists, signature or digest checks, scanning and sandboxed tests. Keep the registry endpoint, service-info, tool and version IDs, descriptor files, image digests and verification sources together.
For a classroom model, compare fictional experiment-card editions rather than executable software.
Section 22 of 36
22. Review scientific validity
A syntactically valid workflow may rely on weak assumptions or unsuitable defaults. Scientific validation needs benchmark evidence and domain review.
Working checkpoint — descriptor type: Compare the workflow’s intended use with the study design. Read every badge beside its verification source, date, scope, fixture and result.
For future study, connect registries to biology, software engineering and cybersecurity while checking official pathways separately.
Section 23 of 36
23. Connect TRS to WES
TRS can supply an exact workflow version and descriptor; WES can submit and monitor its execution. Selecting and running remain separate decisions.
Working checkpoint — container image: Pass an immutable descriptor reference into the WES provenance record. Preserve rejected candidates and version differences; a chosen workflow is not the complete selection process.
For scientific writing, cite the TRS endpoint, tool ID, version and digests.
Section 24 of 36
24. Connect TRS to TES
Containers and task-like tools discovered through TRS may become executors within TES tasks, while TES adds concrete inputs, resources and outputs.
Working checkpoint — verification source: Preserve registry version and image digest in each task. Separate registry discovery and API conformance from scientific validation, licensing and security approval.
For students, ask whether two catalogue entries share a name, a version or identical bytes.
Section 25 of 36
25. Connect TRS to DRS
A workflow may consume data referenced by DRS. Tool identity and data-object identity are independent and both need verification.
Working checkpoint — Tool Registry Service: Store workflow, container and data digests together. Treat descriptor and container digests as scientific identifiers: a silent update can change the executed method.
For parents, ask which checks confirm that a discovered workflow is safe and suitable.
Section 26 of 36
26. Support reproducible citation
A useful citation names registry, tool ID, version, descriptor type, file hashes and container digests rather than only a project name.
Working checkpoint — tool identifier: Generate a machine-readable manifest at selection time. Keep the registry endpoint, service-info, tool and version IDs, descriptor files, image digests and verification sources together.
For a classroom model, compare fictional experiment-card editions rather than executable software.
Section 27 of 36
27. Compare registries carefully
Two registries can expose the same underlying workflow with different identifiers, metadata freshness or verification records.
Working checkpoint — workflow version: Compare descriptor and image digests before declaring equivalence. Read every badge beside its verification source, date, scope, fixture and result.
For future study, connect registries to biology, software engineering and cybersecurity while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A library catalogue helps find an experiment card, but students still need to read the edition, materials and safety notes before using it.
Working checkpoint — descriptor type: Model versions with two clearly different fictional cards. Preserve rejected candidates and version differences; a chosen workflow is not the complete selection process.
For scientific writing, cite the TRS endpoint, tool ID, version and digests.
Section 29 of 36
29. Connect to Secondary Science
Method selection is part of experimental design. The same dataset can support different questions only when the method’s assumptions match.
Working checkpoint — container image: Compare two workflow summaries and justify the better fit. Separate registry discovery and API conformance from scientific validation, licensing and security approval.
For students, ask whether two catalogue entries share a name, a version or identical bytes.
Section 30 of 36
30. Connect to mathematics
Search ranking, versions, sets of supported formats and checksum equality connect registry work to logic and discrete mathematics.
Working checkpoint — verification source: Distinguish “same name”, “same version” and “same bytes”. Treat descriptor and container digests as scientific identifiers: a silent update can change the executed method.
For parents, ask which checks confirm that a discovered workflow is safe and suitable.
Section 31 of 36
31. Connect to computing
APIs, registries, semantic versions, dependency graphs, containers and software supply chains show how infrastructure affects evidence.
Working checkpoint — Tool Registry Service: Test pagination, unsupported descriptors and altered image tags. Keep the registry endpoint, service-info, tool and version IDs, descriptor files, image digests and verification sources together.
For a classroom model, compare fictional experiment-card editions rather than executable software.
Section 32 of 36
32. Connect to pathways
Workflow registries connect genomics, software engineering, reproducibility and cybersecurity and can illuminate STEM pathways.
Working checkpoint — tool identifier: Check current official study and professional requirements separately. Read every badge beside its verification source, date, scope, fixture and result.
For future study, connect registries to biology, software engineering and cybersecurity while checking official pathways separately.
Section 33 of 36
33. Did you know?
TRS v2 added support for multiple container images, multiple authors, multiple verification sources and files associated with a descriptor version.
Working checkpoint — workflow version: Use the richer model to preserve differences rather than flatten them. Preserve rejected candidates and version differences; a chosen workflow is not the complete selection process.
For scientific writing, cite the TRS endpoint, tool ID, version and digests.
Section 34 of 36
34. Write a reader-ready selection report
Name the registry and API version, tool and version IDs, descriptor type, files, authors, images, verification sources, licences, scans and intended use.
Working checkpoint — descriptor type: State clearly which checks were technical and which were scientific. Separate registry discovery and API conformance from scientific validation, licensing and security approval.
For students, ask whether two catalogue entries share a name, a version or identical bytes.
Section 35 of 36
35. Build a validation ladder
Discover candidates, resolve exact versions, download and hash all files, scan images, run a conformance fixture, benchmark scientifically, then approve use.
Working checkpoint — container image: Stop at the first unresolved integrity or permission problem. Treat descriptor and container digests as scientific identifiers: a silent update can change the executed method.
For parents, ask which checks confirm that a discovered workflow is safe and suitable.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver registry responses, service-info, descriptor and image manifests, checksums, licences, scan reports, fixtures, benchmark results and execution links.
Working checkpoint — verification source: Make it possible to reconstruct why this exact version was chosen. Keep the registry endpoint, service-info, tool and version IDs, descriptor files, image digests and verification sources together.
For a classroom model, compare fictional experiment-card editions rather than executable software.
Contents · Previous section · Continue to the Science Learning Hub