eduKateSG · Why Science?
Find many scientific services through one stable registry—while keeping identity, freshness, trust and actual capability separate
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. GA4GH Service Registry is a standard API for grouping and discovering multiple services that implement the Service Info model. GA4GH lists it as current and Support Ready, with v1.0 approved on 5 February 2021. A stable registry address can help clients find services even when individual deployment URLs change, while common metadata lets clients filter or inspect records consistently. An implementation can support the Service Info model directly or inherit it through an upstream GA4GH API. A registry is not automatically a proxy, load balancer, health monitor, trust authority, data catalogue or access-control system, and a listed service is not necessarily reachable, authorised or scientifically appropriate for a particular question. 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 Beacon v2 and federated genomic data discovery; GA4GH Workflow Execution Service and portable workflows; GA4GH Tool Registry Service and discoverable workflows; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH Service Registry product page, current v1.0; Official GA4GH Service Registry specification repository; Official GA4GH Service Info and Registry announcement; 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
Service Registry moves discovery from one service to many. Instead of hard-coding every Beacon, WES, TRS or other endpoint, a client can consult a stable registry and receive service descriptions in a common form. That reduces configuration drift and supports networks whose deployments change. It also creates a new responsibility: the registry must make the source, freshness and identity of each record clear enough that clients do not confuse presence with endorsement.
The relationship with Service Info is the key design boundary. Service Info lets one service describe itself; Service Registry groups records for multiple such services. Some records may be collected from the services, while others may be curated by an operator. If a registry copy and the live endpoint disagree, the client needs a rule for which evidence is authoritative and an audit trail of what it used.
A stable registry URL is useful in federation because individual services can move, scale or be replaced. Stability does not mean immutability. Registries need controlled updates, retirement markers, duplicate handling and refresh monitoring. Clients should cache with expiry, test service identity after resolution and preserve the registry response that selected an endpoint for an important analysis.
Discovery is not execution. A record can identify a WES endpoint without submitting workflows, a Beacon without querying genomic data, or a TRS without downloading descriptors. Each target API retains its own authentication, authorisation, error semantics and scientific scope. This separation keeps the registry simple and lets security teams place distinct controls around metadata discovery and sensitive operations.
Federated registries can themselves form networks, but each extra hop adds trust and freshness questions. A client should detect loops, preserve provenance, limit traversal and avoid silently combining records with conflicting identities. The goal is not the largest possible list. It is a reliable, bounded map of services relevant to a defined community and question.
For students, a registry resembles a library catalogue of laboratories. It can tell you that a facility exists, who operates it and which kind of service it claims to offer. It does not prove the instrument is free, calibrated or suitable for today’s experiment. That cheerful analogy makes a serious systems lesson memorable: finding, trusting and using are different steps, and each step needs its own evidence.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Register | Which services belong in this catalogue? | Service Info-compatible records and governance | A curated discovery set |
| Discover | Which service type or organisation is relevant? | Registry query and stable metadata | Candidate endpoints |
| Verify | Is the selected service live and consistent? | Fresh Service Info and conformance checks | A validated target |
| Use | May this caller perform the operation? | Target API, credentials and scientific policy | A governed service interaction |
Inside this guide
1–12 · Foundations and design
- 1. Start with the discovery scope
- 2. Understand the current standard
- 3. Separate one service from many
- 4. Use a stable registry address
- 5. Read each service record independently
- 6. Support direct or inherited Service Info
- 7. Identify the registry itself
- 8. Filter by service type carefully
- 9. Filter by organisation cautiously
- 10. Treat environment as deployment context
- 11. Preserve the target URL and identity
- 12. Plan record refresh
13–24 · Models and estimation
- 13. Retire services explicitly
- 14. Detect duplicate identities
- 15. Resolve conflicting metadata
- 16. Do not infer health from listing
- 17. Do not infer trust from listing
- 18. Do not infer authorisation from listing
- 19. Do not infer data availability
- 20. Protect public metadata boundaries
- 21. Use secure transport
- 22. Use bearer authentication when needed
- 23. Cache without freezing the network
- 24. Limit registry federation
25–36 · Diagnostics and interpretation
- 25. Preserve discovery provenance
- 26. Connect Registry to Beacon
- 27. Connect Registry to WES and TRS
- 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 discovery report
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with the discovery scope
A registry should define which community, organisation or network it represents. A list with no inclusion rule cannot support a clear trust decision.
Working checkpoint — Service Registry: Write inclusion, update and retirement policies. Keep registry identity, query, record versions, selected endpoints, freshness and live verification together.
For a classroom model, use a fictional laboratory directory with changing status cards.
Section 2 of 36
2. Understand the current standard
GA4GH lists Service Registry as current and Support Ready and identifies v1.0, approved on 5 February 2021, as the last approved version.
Working checkpoint — service record: Record standard and implementation versions. Read every listing beside inclusion policy, provenance, trust domain and the target service response.
For future study, connect registries to distributed systems, governance and research operations while checking official pathways separately.
Section 3 of 36
3. Separate one service from many
Service Info describes one service; Service Registry groups multiple Service Info-compatible records. The distinction prevents a registry from being mistaken for a target API.
Working checkpoint — registry endpoint: Use the registry for selection and the service for action. Preserve duplicates, conflicts, retired entries and unreachable targets; the chosen endpoint is not the complete catalogue state.
For scientific writing, cite the registry response and the live target verification separately.
Section 4 of 36
4. Use a stable registry address
A stable URL can anchor discovery while individual service deployments move or change. The registry response used for an analysis still needs preservation.
Working checkpoint — federated discovery: Archive the exact registry URL and retrieval time. Separate discovery from health, trust, authorisation, data availability and scientific suitability.
For students, ask whether a catalogue entry proves only existence or also availability, safety and suitability.
Section 5 of 36
5. Read each service record independently
Every record carries its own identity, type, version, organisation and environment context. A shared catalogue does not make all entries equivalent.
Working checkpoint — metadata freshness: Validate records one by one before grouping them. Treat registry and service identities as routing-critical inputs: a silent substitution can send work to the wrong endpoint.
For parents, ask who curates the registry and how stale or conflicting entries are handled.
Section 6 of 36
6. Support direct or inherited Service Info
A service can implement the common model directly or through another GA4GH API that embeds it. Clients should recognise the actual service type.
Working checkpoint — trust boundary: Test the advertised upstream contract. Keep registry identity, query, record versions, selected endpoints, freshness and live verification together.
For a classroom model, use a fictional laboratory directory with changing status cards.
Section 7 of 36
7. Identify the registry itself
The registry is also a service and should expose a stable identity and its Service Registry type. This lets clients distinguish catalogues and versions.
Working checkpoint — Service Registry: Store registry identity with every discovered record. Read every listing beside inclusion policy, provenance, trust domain and the target service response.
For future study, connect registries to distributed systems, governance and research operations while checking official pathways separately.
Section 8 of 36
8. Filter by service type carefully
Type-based filtering helps find Beacons, workflow services or registries, but version compatibility and extensions still need checking.
Working checkpoint — service record: Match group, artifact and version rather than a name substring. Preserve duplicates, conflicts, retired entries and unreachable targets; the chosen endpoint is not the complete catalogue state.
For scientific writing, cite the registry response and the live target verification separately.
Section 9 of 36
9. Filter by organisation cautiously
Organisation metadata can narrow a catalogue, yet subsidiaries, collaborations and hosting providers can complicate ownership.
Working checkpoint — registry endpoint: Confirm the operator through governance records. Separate discovery from health, trust, authorisation, data availability and scientific suitability.
For students, ask whether a catalogue entry proves only existence or also availability, safety and suitability.
Section 10 of 36
10. Treat environment as deployment context
Production and test services may coexist. A registry entry should make environment visible, while clients enforce rules about permitted data.
Working checkpoint — federated discovery: Block controlled data from unapproved test endpoints. Treat registry and service identities as routing-critical inputs: a silent substitution can send work to the wrong endpoint.
For parents, ask who curates the registry and how stale or conflicting entries are handled.
Section 11 of 36
11. Preserve the target URL and identity
A URL can change while an identity remains, and a URL can be reused for a replacement service. Both values are needed to detect change.
Working checkpoint — metadata freshness: Compare live Service Info after resolution. Keep registry identity, query, record versions, selected endpoints, freshness and live verification together.
For a classroom model, use a fictional laboratory directory with changing status cards.
Section 12 of 36
12. Plan record refresh
Registry copies become stale when services upgrade, move or close. Refresh schedules should match the operational importance of the catalogue.
Working checkpoint — trust boundary: Measure record age and retry failed refreshes. Read every listing beside inclusion policy, provenance, trust domain and the target service response.
For future study, connect registries to distributed systems, governance and research operations while checking official pathways separately.
Section 13 of 36
13. Retire services explicitly
Silently deleting a record erases history; leaving a dead record active misleads clients. A governed retirement process should preserve provenance.
Working checkpoint — Service Registry: Mark status and dates in an operator record. Preserve duplicates, conflicts, retired entries and unreachable targets; the chosen endpoint is not the complete catalogue state.
For scientific writing, cite the registry response and the live target verification separately.
Section 14 of 36
14. Detect duplicate identities
The same service can appear through direct registration, federation or multiple aliases. Counting records as services can inflate the network.
Working checkpoint — service record: Deduplicate by governed identity and compare URLs. Separate discovery from health, trust, authorisation, data availability and scientific suitability.
For students, ask whether a catalogue entry proves only existence or also availability, safety and suitability.
Section 15 of 36
15. Resolve conflicting metadata
A registry copy, another registry and the live service may report different versions or organisations. Clients need a documented precedence rule.
Working checkpoint — registry endpoint: Flag conflicts instead of silently choosing the newest text. Treat registry and service identities as routing-critical inputs: a silent substitution can send work to the wrong endpoint.
For parents, ask who curates the registry and how stale or conflicting entries are handled.
Section 16 of 36
16. Do not infer health from listing
Presence in a registry does not prove that the endpoint, storage or workers are currently healthy. Discovery and monitoring solve different problems.
Working checkpoint — federated discovery: Run bounded readiness and functional probes. Keep registry identity, query, record versions, selected endpoints, freshness and live verification together.
For a classroom model, use a fictional laboratory directory with changing status cards.
Section 17 of 36
17. Do not infer trust from listing
A catalogue can be open or community-curated. Listing alone is not security approval, scientific endorsement or contractual authority.
Working checkpoint — metadata freshness: Apply an explicit allowlist or trust policy. Read every listing beside inclusion policy, provenance, trust domain and the target service response.
For future study, connect registries to distributed systems, governance and research operations while checking official pathways separately.
Section 18 of 36
18. Do not infer authorisation from listing
A discovered endpoint may require credentials, controlled-access grants or local agreements. The registry does not grant those permissions.
Working checkpoint — trust boundary: Authenticate only after selecting the correct target. Preserve duplicates, conflicts, retired entries and unreachable targets; the chosen endpoint is not the complete catalogue state.
For scientific writing, cite the registry response and the live target verification separately.
Section 19 of 36
19. Do not infer data availability
A service description can be live while its desired dataset, workflow or cohort is absent. The target protocol answers content questions.
Working checkpoint — Service Registry: Issue a minimal authorised discovery request. Separate discovery from health, trust, authorisation, data availability and scientific suitability.
For students, ask whether a catalogue entry proves only existence or also availability, safety and suitability.
Section 20 of 36
20. Protect public metadata boundaries
Registry entries may be publicly useful, yet internal hosts, restricted projects or personal contacts can create security and privacy risk.
Working checkpoint — service record: Review fields before publication and federation. Treat registry and service identities as routing-critical inputs: a silent substitution can send work to the wrong endpoint.
For parents, ask who curates the registry and how stale or conflicting entries are handled.
Section 21 of 36
21. Use secure transport
The specification follows Service Info security guidance, including TLS 1.2 or higher when sensitive information is transported.
Working checkpoint — registry endpoint: Validate certificates and prevent downgrade. Keep registry identity, query, record versions, selected endpoints, freshness and live verification together.
For a classroom model, use a fictional laboratory directory with changing status cards.
Section 22 of 36
22. Use bearer authentication when needed
A registry can protect sensitive catalogues with OAuth 2 bearer credentials. Authentication to the registry is separate from authentication to a target service.
Working checkpoint — federated discovery: Use different scoped tokens for each boundary. Read every listing beside inclusion policy, provenance, trust domain and the target service response.
For future study, connect registries to distributed systems, governance and research operations while checking official pathways separately.
Section 23 of 36
23. Cache without freezing the network
Cached results improve resilience but can keep retired endpoints or old versions alive in clients. Cache policies need explicit expiry and revalidation.
Working checkpoint — metadata freshness: Record cache age in every selection decision. Preserve duplicates, conflicts, retired entries and unreachable targets; the chosen endpoint is not the complete catalogue state.
For scientific writing, cite the registry response and the live target verification separately.
Section 24 of 36
24. Limit registry federation
Following registries recursively can create loops, huge result sets and mixed trust domains. Federation should be bounded by purpose and policy.
Working checkpoint — trust boundary: Set depth, domain and record limits. Separate discovery from health, trust, authorisation, data availability and scientific suitability.
For students, ask whether a catalogue entry proves only existence or also availability, safety and suitability.
Section 25 of 36
25. Preserve discovery provenance
An analysis should reveal which registry response selected each endpoint and what live verification followed. Otherwise a later audit cannot reconstruct routing.
Working checkpoint — Service Registry: Create a selection manifest before use. Treat registry and service identities as routing-critical inputs: a silent substitution can send work to the wrong endpoint.
For parents, ask who curates the registry and how stale or conflicting entries are handled.
Section 26 of 36
26. Connect Registry to Beacon
A registry can help locate Beacon services, while Beacon handles genomic discovery queries under its own model and permissions.
Working checkpoint — service record: Verify the Beacon type and live version before querying. Keep registry identity, query, record versions, selected endpoints, freshness and live verification together.
For a classroom model, use a fictional laboratory directory with changing status cards.
Section 27 of 36
27. Connect Registry to WES and TRS
A catalogue can locate workflow execution and tool registry services. WES still runs workflows, while TRS still resolves exact tool versions.
Working checkpoint — registry endpoint: Keep discovery, selection and execution records separate. Read every listing beside inclusion policy, provenance, trust domain and the target service response.
For future study, connect registries to distributed systems, governance and research operations while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A directory of school laboratories says where facilities are, not whether equipment is available or safe for a particular activity.
Working checkpoint — federated discovery: Use fictional facilities and status cards. Preserve duplicates, conflicts, retired entries and unreachable targets; the chosen endpoint is not the complete catalogue state.
For scientific writing, cite the registry response and the live target verification separately.
Section 29 of 36
29. Connect to Secondary Science
Scientific networks depend on traceable instruments, methods and providers. A registry makes the software-service layer visible in a methods chain.
Working checkpoint — metadata freshness: Add registry and target identities to a mock report. Separate discovery from health, trust, authorisation, data availability and scientific suitability.
For students, ask whether a catalogue entry proves only existence or also availability, safety and suitability.
Section 30 of 36
30. Connect to mathematics
Sets, filters, graphs, duplicates, freshness intervals and bounded traversal connect registry discovery to discrete mathematics.
Working checkpoint — trust boundary: Draw a small network and detect a loop. Treat registry and service identities as routing-critical inputs: a silent substitution can send work to the wrong endpoint.
For parents, ask who curates the registry and how stale or conflicting entries are handled.
Section 31 of 36
31. Connect to computing
APIs, service discovery, caching, federation, TLS and identity show how distributed systems support scientific collaboration.
Working checkpoint — Service Registry: Test duplicate, stale, unreachable and conflicting records. Keep registry identity, query, record versions, selected endpoints, freshness and live verification together.
For a classroom model, use a fictional laboratory directory with changing status cards.
Section 32 of 36
32. Connect to pathways
Service registries connect computing, research infrastructure, cybersecurity and governance and can illuminate STEM pathways.
Working checkpoint — service record: Check current official qualifications and role requirements separately. Read every listing beside inclusion policy, provenance, trust domain and the target service response.
For future study, connect registries to distributed systems, governance and research operations while checking official pathways separately.
Section 33 of 36
33. Did you know?
A stable registry endpoint can help clients find services whose individual URLs change, but the client still needs to verify the live service after discovery.
Working checkpoint — registry endpoint: Treat registry resolution like a map, not a guarantee. Preserve duplicates, conflicts, retired entries and unreachable targets; the chosen endpoint is not the complete catalogue state.
For scientific writing, cite the registry response and the live target verification separately.
Section 34 of 36
34. Write a reader-ready discovery report
Name registry identity and version, query, response time, selected service records, freshness, conflicts, live checks and target permissions.
Working checkpoint — federated discovery: List excluded or unreachable candidates. Separate discovery from health, trust, authorisation, data availability and scientific suitability.
For students, ask whether a catalogue entry proves only existence or also availability, safety and suitability.
Section 35 of 36
35. Build a validation ladder
Validate the registry, test filters, detect duplicates and loops, compare live Service Info, review trust, then call a minimal target operation.
Working checkpoint — metadata freshness: Stop when identity or authorisation is unresolved. Treat registry and service identities as routing-critical inputs: a silent substitution can send work to the wrong endpoint.
For parents, ask who curates the registry and how stale or conflicting entries are handled.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver registry responses, query and cache record, service identities and URLs, live metadata, trust rules, test results and downstream interaction links.
Working checkpoint — trust boundary: Make every endpoint selection reconstructable. Keep registry identity, query, record versions, selected endpoints, freshness and live verification together.
For a classroom model, use a fictional laboratory directory with changing status cards.
Contents · Previous section · Continue to the Science Learning Hub