eduKateSG · Why Science?
Ask a distributed network a precise genomic question—then read the response in the context of permissions, models, uncertainty and privacy risk
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 Beacon API is a standard for discovering genomic and related data across distributed resources. The official product page lists version 2.0 as approved and current. Beacon v1 became known for simple allele-existence questions; Beacon v2 adds a framework and models for richer queries across genomic variations, individuals, biosamples, cohorts, runs and analyses, with response detail governed by the implementation and access level. Federation can make resources discoverable without requiring one universal database, but it does not eliminate privacy, authorisation, security or re-identification risks. 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 VRS and computable variant representation; Matchmaker Exchange and federated rare-disease matching; Human Phenotype Ontology and structured clinical phenotypes; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH Beacon API product page, version 2.0; Official GA4GH Beacon v2 documentation; Beacon v2 framework documentation; Beacon v2 reference implementation study; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Resource interfaces and recommendations can change, so preserve the release, access date and documentation used.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Discover | Which Beacon endpoint and entry type can answer the question? | Service metadata, model and network catalogue | A reachable, compatible endpoint |
| Query | Which variant, individual, biosample or cohort constraints apply? | Request parameters, filters and identifiers | A precise, reproducible request |
| Respond | What is the caller allowed to learn? | Boolean, count, record detail and access policy | A controlled response with scope |
| Govern | Could the query or response expose a person or restricted dataset? | Authentication, authorisation, logging and risk review | A permitted and auditable discovery |
Inside this guide
1–12 · Foundations and design
- 1. Start with federated discovery
- 2. Understand the Beacon lineage
- 3. Know the approved version
- 4. Separate framework from model
- 5. Read service metadata first
- 6. Choose the entry type
- 7. Build a variant query precisely
- 8. Use filters deliberately
- 9. Understand request parameters
- 10. Read boolean responses narrowly
- 11. Read counts with denominators
- 12. Read record-level responses carefully
13–24 · Models and estimation
- 13. Use result sets
- 14. Follow identifiers and references
- 15. Connect with VRS
- 16. Connect with Phenopackets cautiously
- 17. Understand Beacon networks
- 18. Do not mistake federation for no movement
- 19. Expect heterogeneous coverage
- 20. Version models and configurations
- 21. Authenticate the caller
- 22. Authorise the action
- 23. Treat privacy as a scientific constraint
- 24. Log and audit responsibly
25–36 · Diagnostics and interpretation
- 25. Plan rate and abuse controls
- 26. Separate discovery from access
- 27. Reproduce network queries
- 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 query report
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with federated discovery
Beacon lets distributed data providers answer standardised queries while retaining control of their own services and policies.
Working checkpoint — GA4GH Beacon: Write what must be discovered and why federation is needed. Keep the request, endpoint list, service metadata, model version, access context and every response together.
For a classroom model, use fictional library catalogues rather than genomic data.
Section 2 of 36
2. Understand the Beacon lineage
Beacon v1 popularised a simple question about whether a particular allele had been observed. Beacon v2 supports richer entities and responses.
Working checkpoint — federated query: Name the Beacon version rather than mixing behaviours. Read a match, count or record beside the searched dataset and response policy.
For future study, connect federation to biology, cybersecurity, statistics and policy while checking official pathways separately.
Section 3 of 36
3. Know the approved version
GA4GH lists Beacon API version 2.0 as the last approved version and dates its production approval to 21 June 2022.
Working checkpoint — entry type: Record the endpoint and model version used. Preserve failures, redactions and non-responses; a network summary is not the complete query.
For scientific writing, name the Beacon version, nodes, filters and response granularity.
Section 4 of 36
4. Separate framework from model
The v2 framework defines common request, response and service behaviour; models define domain entry types and their properties.
Working checkpoint — filter: Check both layers for compatibility. Separate data discovery from data access, diagnosis and prevalence inference.
For students, ask which network nodes were queried and what each response actually means.
Section 5 of 36
5. Read service metadata first
A Beacon describes its organisation, schemas, datasets, supported features and security context.
Working checkpoint — response granularity: Discover capabilities before sending a scientific query. Treat assembly, coordinates, filters and authorisation tiers as scientific inputs: a silent mismatch can change the answer.
For parents, ask what information leaves each organisation and who is allowed to receive it.
Section 6 of 36
6. Choose the entry type
Beacon v2 models include genomic variations, individuals, biosamples, cohorts, analyses and runs. Each answers a different question.
Working checkpoint — access policy: Use the narrowest entry type that matches the purpose. Keep the request, endpoint list, service metadata, model version, access context and every response together.
For a classroom model, use fictional library catalogues rather than genomic data.
Section 7 of 36
7. Build a variant query precisely
A genomic query needs reference assembly, sequence reference, position or interval and allele representation appropriate to the endpoint.
Working checkpoint — GA4GH Beacon: Normalise and verify the variant before querying. Read a match, count or record beside the searched dataset and response policy.
For future study, connect federation to biology, cybersecurity, statistics and policy while checking official pathways separately.
Section 8 of 36
8. Use filters deliberately
Filters can constrain disease, phenotype, sex, ancestry, assay or other indexed attributes when supported.
Working checkpoint — federated query: Record the filter ontology and exact value. Preserve failures, redactions and non-responses; a network summary is not the complete query.
For scientific writing, name the Beacon version, nodes, filters and response granularity.
Section 9 of 36
9. Understand request parameters
Pagination, requested schemas, include-result settings and test mode can change the returned payload.
Working checkpoint — entry type: Archive the complete request, not only a URL fragment. Separate data discovery from data access, diagnosis and prevalence inference.
For students, ask which network nodes were queried and what each response actually means.
Section 10 of 36
10. Read boolean responses narrowly
A true response means a match exists under that endpoint’s query interpretation and caller access; it is not a diagnosis or population prevalence estimate.
Working checkpoint — filter: State endpoint, dataset and query scope. Treat assembly, coordinates, filters and authorisation tiers as scientific inputs: a silent mismatch can change the answer.
For parents, ask what information leaves each organisation and who is allowed to receive it.
Section 11 of 36
11. Read counts with denominators
A count needs the searched dataset, eligibility rules, update date and suppression policy.
Working checkpoint — response granularity: Do not convert a count into frequency without a valid denominator. Keep the request, endpoint list, service metadata, model version, access context and every response together.
For a classroom model, use fictional library catalogues rather than genomic data.
Section 12 of 36
12. Read record-level responses carefully
Detailed records can include rich attributes when policy allows, but fields may be redacted, aggregated or unavailable.
Working checkpoint — access policy: Distinguish absent data from withheld data. Read a match, count or record beside the searched dataset and response policy.
For future study, connect federation to biology, cybersecurity, statistics and policy while checking official pathways separately.
Section 13 of 36
13. Use result sets
Beacon v2 responses can organise matches into result sets tied to datasets and schemas.
Working checkpoint — GA4GH Beacon: Keep dataset identity with every returned record. Preserve failures, redactions and non-responses; a network summary is not the complete query.
For scientific writing, name the Beacon version, nodes, filters and response granularity.
Section 14 of 36
14. Follow identifiers and references
Stable identifiers help join records, but equivalent variants and phenotype concepts can still use different representations.
Working checkpoint — federated query: Resolve identifiers through the documented namespace. Separate data discovery from data access, diagnosis and prevalence inference.
For students, ask which network nodes were queried and what each response actually means.
Section 15 of 36
15. Connect with VRS
GA4GH VRS can make variant representation more computable across services, reducing ambiguity in what is being asked.
Working checkpoint — entry type: Preserve assembly and reference sequence context. Treat assembly, coordinates, filters and authorisation tiers as scientific inputs: a silent mismatch can change the answer.
For parents, ask what information leaves each organisation and who is allowed to receive it.
Section 16 of 36
16. Connect with Phenopackets cautiously
Phenotype-rich case representations can complement Beacon discovery, but not every endpoint exposes the same fields or mappings.
Working checkpoint — filter: Test the advertised schema rather than assuming support. Keep the request, endpoint list, service metadata, model version, access context and every response together.
For a classroom model, use fictional library catalogues rather than genomic data.
Section 17 of 36
17. Understand Beacon networks
Aggregators can send a query to multiple Beacons and collect responses, extending discovery across a network.
Working checkpoint — response granularity: Record which nodes responded, failed or timed out. Read a match, count or record beside the searched dataset and response policy.
For future study, connect federation to biology, cybersecurity, statistics and policy while checking official pathways separately.
Section 18 of 36
18. Do not mistake federation for no movement
An implementation may return metadata, counts or records across network boundaries even if source databases remain distributed.
Working checkpoint — access policy: Describe actual request and response flows. Preserve failures, redactions and non-responses; a network summary is not the complete query.
For scientific writing, name the Beacon version, nodes, filters and response granularity.
Section 19 of 36
19. Expect heterogeneous coverage
Different nodes contain different populations, assays, inclusion criteria and update schedules.
Working checkpoint — GA4GH Beacon: Treat non-response and no-match as endpoint-specific evidence. Separate data discovery from data access, diagnosis and prevalence inference.
For students, ask which network nodes were queried and what each response actually means.
Section 20 of 36
20. Version models and configurations
Endpoints can update schemas, datasets and filtering behaviour independently.
Working checkpoint — federated query: Capture service-info, model and query date. Treat assembly, coordinates, filters and authorisation tiers as scientific inputs: a silent mismatch can change the answer.
For parents, ask what information leaves each organisation and who is allowed to receive it.
Section 21 of 36
21. Authenticate the caller
Some Beacons are public while controlled tiers require identity and credentials. Authentication answers who the caller is.
Working checkpoint — entry type: Use approved institutional access. Keep the request, endpoint list, service metadata, model version, access context and every response together.
For a classroom model, use fictional library catalogues rather than genomic data.
Section 22 of 36
22. Authorise the action
Authorisation determines which datasets, query types and response granularity a caller may access.
Working checkpoint — filter: Test least-privilege roles. Read a match, count or record beside the searched dataset and response policy.
For future study, connect federation to biology, cybersecurity, statistics and policy while checking official pathways separately.
Section 23 of 36
23. Treat privacy as a scientific constraint
Repeated presence queries, rare variants and small cohorts can create re-identification risk.
Working checkpoint — response granularity: Apply threat modelling, suppression and query controls. Preserve failures, redactions and non-responses; a network summary is not the complete query.
For scientific writing, name the Beacon version, nodes, filters and response granularity.
Section 24 of 36
24. Log and audit responsibly
Logs help investigate misuse and reproduce authorised work, yet query logs can also contain sensitive genomic targets.
Working checkpoint — access policy: Protect logs with retention and access rules. Separate data discovery from data access, diagnosis and prevalence inference.
For students, ask which network nodes were queried and what each response actually means.
Section 25 of 36
25. Plan rate and abuse controls
Automated enumeration can turn individually modest responses into a privacy attack.
Working checkpoint — GA4GH Beacon: Use rate limits and anomaly detection suited to risk. Treat assembly, coordinates, filters and authorisation tiers as scientific inputs: a silent mismatch can change the answer.
For parents, ask what information leaves each organisation and who is allowed to receive it.
Section 26 of 36
26. Separate discovery from access
Learning that relevant data may exist does not automatically grant access to row-level data or samples.
Working checkpoint — federated query: Follow the dataset’s formal access process. Keep the request, endpoint list, service metadata, model version, access context and every response together.
For a classroom model, use fictional library catalogues rather than genomic data.
Section 27 of 36
27. Reproduce network queries
Endpoints can change and some nodes may be temporarily unavailable. A reproducible record includes node list, request, time and all statuses.
Working checkpoint — entry type: Store failures beside successes. Read a match, count or record beside the searched dataset and response policy.
For future study, connect federation to biology, cybersecurity, statistics and policy while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A fictional library network can answer whether it holds a type of book without sending every catalogue to one building.
Working checkpoint — filter: Keep the analogy separate from human genomic privacy. Preserve failures, redactions and non-responses; a network summary is not the complete query.
For scientific writing, name the Beacon version, nodes, filters and response granularity.
Section 29 of 36
29. Connect to Secondary Science
Variation, inheritance, databases and evidence become a question about how biological records are discovered across institutions.
Working checkpoint — response granularity: Ask what a yes answer does and does not prove. Separate data discovery from data access, diagnosis and prevalence inference.
For students, ask which network nodes were queried and what each response actually means.
Section 30 of 36
30. Connect to mathematics
Counts, denominators, suppression and repeated-query risk show why aggregation changes interpretation.
Working checkpoint — access policy: Calculate a toy proportion only after defining the searched population. Treat assembly, coordinates, filters and authorisation tiers as scientific inputs: a silent mismatch can change the answer.
For parents, ask what information leaves each organisation and who is allowed to receive it.
Section 31 of 36
31. Connect to computing
APIs, schemas, federation, authentication and logs turn interoperability into an engineering and governance problem.
Working checkpoint — GA4GH Beacon: Validate requests and fail visibly on partial network results. Keep the request, endpoint list, service metadata, model version, access context and every response together.
For a classroom model, use fictional library catalogues rather than genomic data.
Section 32 of 36
32. Connect to pathways
Genomic federation joins biology, cybersecurity, software, statistics and policy and can illuminate STEM pathways.
Working checkpoint — federated query: Check current official study and professional requirements separately. Read a match, count or record beside the searched dataset and response policy.
For future study, connect federation to biology, cybersecurity, statistics and policy while checking official pathways separately.
Section 33 of 36
33. Did you know?
Beacon v2 can query more than genomic variants: its official models include individuals, biosamples, cohorts, analyses and runs.
Working checkpoint — entry type: Ask only for the entity and detail needed. Preserve failures, redactions and non-responses; a network summary is not the complete query.
For scientific writing, name the Beacon version, nodes, filters and response granularity.
Section 34 of 36
34. Write a reader-ready query report
Name the version, endpoints, entry type, variant representation, filters, response tier, failures, access basis and interpretation limits.
Working checkpoint — filter: Keep discovery separate from diagnosis and data access. Separate data discovery from data access, diagnosis and prevalence inference.
For students, ask which network nodes were queried and what each response actually means.
Section 35 of 36
35. Build a validation ladder
Validate the variant and model, test one node, inspect response semantics, expand to a network, then audit privacy and completeness.
Working checkpoint — response granularity: Do not let aggregation hide incompatible nodes. Treat assembly, coordinates, filters and authorisation tiers as scientific inputs: a silent mismatch can change the answer.
For parents, ask what information leaves each organisation and who is allowed to receive it.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver the permitted request, node manifest, service metadata, raw responses, timestamps, errors, access context, transformation code and bounded conclusion.
Working checkpoint — access policy: Make discovery auditable without exposing restricted records. Keep the request, endpoint list, service metadata, model version, access context and every response together.
For a classroom model, use fictional library catalogues rather than genomic data.
Contents · Previous section · Continue to the Science Learning Hub