eduKateSG · Why Science?
Describe one compute task clearly enough for a cloud, cluster or high-performance system to execute—and audit it
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 Task Execution Service, or TES, is a standard API and schema for describing and executing asynchronous batch tasks. GA4GH lists TES as a current product and v1.1 as the last approved version; the live reference documentation identifies TES 1.1.0. A task can declare input files, output destinations, sequential executors, shared volumes, requested CPU, memory and disk, plus logs and metadata. TES can wrap cloud or high-performance-computing backends, but it does not schedule an entire scientific workflow by itself, grant access to controlled data, guarantee resource availability or validate the biological meaning of an output. 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; Crypt4GH and encrypted genomic files; htsget and secure genomic streaming; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH Task Execution Service product page, current TES v1.1; Official GA4GH TES 1.1.0 API documentation; Official GA4GH TES specification repository; TES API peer-reviewed paper; 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
TES makes a compute task resemble a laboratory work order. Inputs must arrive at named places, equipment must meet stated capacity, commands must run in order, temporary workspace must be available and products must be delivered to declared destinations. That structure is useful precisely because a task can otherwise inherit dozens of invisible defaults from one cluster or cloud. The schema does not remove operational judgement; it gives that judgement a common place to be recorded and tested.
The distinction between task and workflow matters. A workflow may decide that alignment must precede variant calling, branch samples in parallel, retry transient failures and combine outputs. A TES task describes one executable batch unit inside that plan. Packing too much orchestration into a single task can make failures opaque, while splitting every command into tiny tasks can create overhead and provenance noise. The right boundary follows meaningful inputs, outputs and recovery points.
Resource requests are scientific-operational hypotheses. CPU, memory, disk and locality influence whether a task starts, how long it runs, what it costs and whether it fails. They can also affect reproducibility when software changes behaviour with thread count or hardware. A robust benchmark varies data size, captures peak use and records the backend. It treats a successful run on one small example as an initial observation, not proof that every cohort will fit.
TES also makes failure taxonomy practical. A command that exits non-zero suggests an executor problem; a broken transfer, node loss or upload failure points toward the surrounding system. Preemption raises a different question: can the task restart safely without duplicating or overwriting results? Keeping task attempts immutable and linking them to one higher-level workflow run lets a team answer these questions without losing the history that explains the final output.
For a student, the lesson is cheerful and concrete: good instructions make collaboration possible. For a production genomics team, the same principle protects sensitive data and expensive computation. The best task document is not the longest one; it is the smallest complete description that lets an authorised backend reproduce the intended work, expose failures honestly and return verifiable products.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Stage | Which files and locations are required? | Input URLs, paths, types and authorised access | A staged task workspace |
| Run | Which commands execute in which images? | Sequential executors, images, commands and volumes | A bounded batch computation |
| Resource | What capacity and locality are needed? | CPU, RAM, disk, zones and backend parameters | A schedulable request |
| Return | Which outputs and logs prove what happened? | Output URLs, task state, executor logs and checksums | A traceable task result |
Inside this guide
1–12 · Foundations and design
- 1. Start with one bounded task
- 2. Understand the current specification
- 3. Separate task from workflow
- 4. Use the asynchronous model
- 5. Map cloud and HPC backends
- 6. Bring compute to data
- 7. Name inputs explicitly
- 8. Protect input credentials
- 9. Validate destination paths
- 10. Describe outputs before execution
- 11. Use content checksums
- 12. Describe executors precisely
13–24 · Models and estimation
- 13. Respect sequential executors
- 14. Use volumes for shared state
- 15. Capture standard output and error
- 16. Request CPU realistically
- 17. Request RAM realistically
- 18. Request disk for staging and intermediates
- 19. Treat zones and locality as governance inputs
- 20. Use backend parameters sparingly
- 21. Choose preemptible compute deliberately
- 22. Read task states carefully
- 23. Use view levels appropriately
- 24. Cancel idempotently
25–36 · Diagnostics and interpretation
- 25. Separate executor and system failure
- 26. Connect TES to WES
- 27. Connect TES to DRS
- 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 task report
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with one bounded task
TES is strongest when a unit of computation has explicit inputs, commands, outputs and resource needs. A vague “run the analysis” request hides too many assumptions.
Working checkpoint — Task Execution Service: Write the task boundary and success condition before choosing a backend. Keep the task document, input manifest, image digests, resources, task ID, states, logs and output checksums together.
For a classroom model, use safe job cards and empty shared folders rather than real data.
Section 2 of 36
2. Understand the current specification
GA4GH lists TES v1.1 as current, while the official API documentation identifies version 1.1.0.
Working checkpoint — task document: Record both product and exact schema version used by the client and server. Read every failure beside executor exit codes, staging, system logs and upload status.
For future study, connect task execution to biology, distributed systems and security while checking official pathways separately.
Section 3 of 36
3. Separate task from workflow
A task is a batch unit; a workflow can contain many dependent tasks with branching and retries. TES may be used underneath a workflow engine but is not the whole workflow language.
Working checkpoint — executor: Keep orchestration logic outside the task document unless explicitly represented. Preserve all attempts and resource changes; a final successful task is not the complete operational record.
For scientific writing, name TES, task, image and resource versions.
Section 4 of 36
4. Use the asynchronous model
A TES server accepts a task and executes it later on available resources. The caller receives an ID and polls state rather than holding one long connection.
Working checkpoint — input mapping: Design clients for delay, retries and eventual terminal states. Separate task execution from workflow orchestration, data permission and biological interpretation.
For students, ask which materials, workspace and commands make the job reproducible.
Section 5 of 36
5. Map cloud and HPC backends
A TES implementation can sit over Kubernetes, cloud batch services or traditional high-performance-computing queues such as Slurm.
Working checkpoint — resource request: Test the same conformance task on every backend class you intend to use. Treat file paths, URLs, image digests and units as scientific inputs: a silent mismatch can run the wrong computation.
For parents, ask who may stage the data and where outputs are allowed to go.
Section 6 of 36
6. Bring compute to data
TES can help send defined computation to a location where governed data already reside, reducing unnecessary movement.
Working checkpoint — task log: Confirm whether outputs may leave the data environment. Keep the task document, input manifest, image digests, resources, task ID, states, logs and output checksums together.
For a classroom model, use safe job cards and empty shared folders rather than real data.
Section 7 of 36
7. Name inputs explicitly
Input objects map source URLs to paths inside the task workspace and can represent files or directories.
Working checkpoint — Task Execution Service: Create a manifest with type, destination path, size and checksum. Read every failure beside executor exit codes, staging, system logs and upload status.
For future study, connect task execution to biology, distributed systems and security while checking official pathways separately.
Section 8 of 36
8. Protect input credentials
A source URL may require cloud credentials, signed access or headers. Those capabilities should be scoped and short-lived.
Working checkpoint — task document: Keep secrets out of task names, logs and long-lived metadata. Preserve all attempts and resource changes; a final successful task is not the complete operational record.
For scientific writing, name TES, task, image and resource versions.
Section 9 of 36
9. Validate destination paths
Input paths and output paths define the task filesystem. Collisions, traversal or wrong mounts can silently change what an executor reads.
Working checkpoint — executor: Normalize paths and reject unsafe or duplicate mappings. Separate task execution from workflow orchestration, data permission and biological interpretation.
For students, ask which materials, workspace and commands make the job reproducible.
Section 10 of 36
10. Describe outputs before execution
Output objects map task paths to destinations and types. A job that computes correctly can still fail while uploading results.
Working checkpoint — input mapping: Check output permissions, naming and available storage in advance. Treat file paths, URLs, image digests and units as scientific inputs: a silent mismatch can run the wrong computation.
For parents, ask who may stage the data and where outputs are allowed to go.
Section 11 of 36
11. Use content checksums
TES moves bytes between object stores and compute nodes; checksums help detect truncation or substitution.
Working checkpoint — resource request: Verify inputs after staging and outputs after upload. Keep the task document, input manifest, image digests, resources, task ID, states, logs and output checksums together.
For a classroom model, use safe job cards and empty shared folders rather than real data.
Section 12 of 36
12. Describe executors precisely
Each executor names a container image, command and optional working directory, standard streams and environment. Floating image tags make results hard to reproduce.
Working checkpoint — task log: Pin images by digest and store the exact command array. Read every failure beside executor exit codes, staging, system logs and upload status.
For future study, connect task execution to biology, distributed systems and security while checking official pathways separately.
Section 13 of 36
13. Respect sequential executors
TES 1.1 runs executors one at a time in order and stops on the first error. Later executors can depend on files made by earlier ones.
Working checkpoint — Task Execution Service: Document intermediate files and deliberate failure behaviour. Preserve all attempts and resource changes; a final successful task is not the complete operational record.
For scientific writing, name TES, task, image and resource versions.
Section 14 of 36
14. Use volumes for shared state
Declared volumes are empty directories mounted at the same path for all executors, allowing one step to pass files to the next.
Working checkpoint — task document: Treat volumes as ephemeral unless the implementation promises persistence. Separate task execution from workflow orchestration, data permission and biological interpretation.
For students, ask which materials, workspace and commands make the job reproducible.
Section 15 of 36
15. Capture standard output and error
Executor stdout and stderr can explain failure, progress and software behaviour but may also expose secrets or data values.
Working checkpoint — executor: Route logs deliberately and redact without destroying diagnostic context. Treat file paths, URLs, image digests and units as scientific inputs: a silent mismatch can run the wrong computation.
For parents, ask who may stage the data and where outputs are allowed to go.
Section 16 of 36
16. Request CPU realistically
CPU cores influence scheduling, parallelism and cost. Asking for too little can slow or fail a task; asking for too much can delay placement.
Working checkpoint — input mapping: Benchmark a representative fixture and record utilisation. Keep the task document, input manifest, image digests, resources, task ID, states, logs and output checksums together.
For a classroom model, use safe job cards and empty shared folders rather than real data.
Section 17 of 36
17. Request RAM realistically
Memory needs depend on data size, algorithms and implementation. Out-of-memory failures can be mistaken for software bugs.
Working checkpoint — resource request: Measure peak memory and add justified headroom. Read every failure beside executor exit codes, staging, system logs and upload status.
For future study, connect task execution to biology, distributed systems and security while checking official pathways separately.
Section 18 of 36
18. Request disk for staging and intermediates
Local disk must cover inputs, expanded files, temporary products and outputs. Compressed input size alone can be misleading.
Working checkpoint — task log: Estimate worst-case temporary storage before scaling. Preserve all attempts and resource changes; a final successful task is not the complete operational record.
For scientific writing, name TES, task, image and resource versions.
Section 19 of 36
19. Treat zones and locality as governance inputs
Zone choices can affect data residency, latency, egress cost and availability. A technically reachable zone may still be prohibited.
Working checkpoint — Task Execution Service: Check policy and data location before setting resource locality. Separate task execution from workflow orchestration, data permission and biological interpretation.
For students, ask which materials, workspace and commands make the job reproducible.
Section 20 of 36
20. Use backend parameters sparingly
Backend-specific parameters expose features not covered by the common model, but they weaken portability and can be rejected in strict mode.
Working checkpoint — task document: Document why each extension is required and maintain a portable fallback. Treat file paths, URLs, image digests and units as scientific inputs: a silent mismatch can run the wrong computation.
For parents, ask who may stage the data and where outputs are allowed to go.
Section 21 of 36
21. Choose preemptible compute deliberately
Preemptible resources can reduce cost but may be reclaimed. Suitability depends on restartability, checkpoints and deadline.
Working checkpoint — executor: Test interruption recovery before using them for irreplaceable work. Keep the task document, input manifest, image digests, resources, task ID, states, logs and output checksums together.
For a classroom model, use safe job cards and empty shared folders rather than real data.
Section 22 of 36
22. Read task states carefully
State transitions distinguish queuing, initialization, running, completion, cancellation and error conditions. Different failures call for different responses.
Working checkpoint — input mapping: Preserve timestamps and never infer success from disappearance from a queue. Read every failure beside executor exit codes, staging, system logs and upload status.
For future study, connect task execution to biology, distributed systems and security while checking official pathways separately.
Section 23 of 36
23. Use view levels appropriately
TES can expose minimal, basic or full task views so a caller retrieves only the detail needed and permitted.
Working checkpoint — resource request: Request the least detailed view that supports the decision. Preserve all attempts and resource changes; a final successful task is not the complete operational record.
For scientific writing, name TES, task, image and resource versions.
Section 24 of 36
24. Cancel idempotently
A cancellation request may race with completion or other callers. Clients must handle already-terminal tasks without creating contradictory records.
Working checkpoint — task log: Record who requested cancellation and the observed final state. Separate task execution from workflow orchestration, data permission and biological interpretation.
For students, ask which materials, workspace and commands make the job reproducible.
Section 25 of 36
25. Separate executor and system failure
A non-zero command exit differs from failed input staging, node loss or output upload. The repair path depends on the layer.
Working checkpoint — Task Execution Service: Classify the failure from executor and system logs before retry. Treat file paths, URLs, image digests and units as scientific inputs: a silent mismatch can run the wrong computation.
For parents, ask who may stage the data and where outputs are allowed to go.
Section 26 of 36
26. Connect TES to WES
A WES implementation may translate a portable workflow into many TES tasks. WES run IDs and TES task IDs describe related but different levels.
Working checkpoint — task document: Maintain a provenance map from workflow run to every task attempt. Keep the task document, input manifest, image digests, resources, task ID, states, logs and output checksums together.
For a classroom model, use safe job cards and empty shared folders rather than real data.
Section 27 of 36
27. Connect TES to DRS
DRS object IDs can identify logical inputs while TES stages concrete access methods. Access URLs may expire even when the DRS ID remains stable.
Working checkpoint — executor: Preserve both the logical ID and actual verified transfer record. Read every failure beside executor exit codes, staging, system logs and upload status.
For future study, connect task execution to biology, distributed systems and security while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A classroom job card can list materials, steps, workspace and expected product, showing why complete instructions matter.
Working checkpoint — input mapping: Use a safe manual activity and compare missing-field failures. Preserve all attempts and resource changes; a final successful task is not the complete operational record.
For scientific writing, name TES, task, image and resource versions.
Section 29 of 36
29. Connect to Secondary Science
Controlled variables, equipment limits and recorded observations have close parallels in compute resources, container images and task logs.
Working checkpoint — resource request: Ask which resource changes could alter timing without altering the scientific question. Separate task execution from workflow orchestration, data permission and biological interpretation.
For students, ask which materials, workspace and commands make the job reproducible.
Section 30 of 36
30. Connect to mathematics
Capacity planning uses units, ratios, upper bounds and distributions. Resource requests should be measurable hypotheses rather than guesses.
Working checkpoint — task log: Graph runtime, memory and data size for repeated fixtures. Treat file paths, URLs, image digests and units as scientific inputs: a silent mismatch can run the wrong computation.
For parents, ask who may stage the data and where outputs are allowed to go.
Section 31 of 36
31. Connect to computing
Containers, paths, queues, APIs, exit codes and idempotency make TES a compact systems-engineering lesson.
Working checkpoint — Task Execution Service: Test wrong paths, missing images, insufficient disk and interrupted uploads. Keep the task document, input manifest, image digests, resources, task ID, states, logs and output checksums together.
For a classroom model, use safe job cards and empty shared folders rather than real data.
Section 32 of 36
32. Connect to pathways
Portable task execution links life science, distributed systems, cloud engineering and security and can illuminate STEM pathways.
Working checkpoint — task document: Check current official study and professional requirements separately. Read every failure beside executor exit codes, staging, system logs and upload status.
For future study, connect task execution to biology, distributed systems and security while checking official pathways separately.
Section 33 of 36
33. Did you know?
TES executors share declared volumes and run sequentially, so one executor can create a file that the next consumes without embedding a workflow engine inside the task.
Working checkpoint — executor: Keep the sequence short and explicit; use a workflow system for wider orchestration. Preserve all attempts and resource changes; a final successful task is not the complete operational record.
For scientific writing, name TES, task, image and resource versions.
Section 34 of 36
34. Write a reader-ready task report
Name TES and implementation versions, task ID, inputs, checksums, images, commands, resources, states, logs, outputs, backend and permissions.
Working checkpoint — input mapping: Redact capabilities while keeping every scientific dependency identifiable. Separate task execution from workflow orchestration, data permission and biological interpretation.
For students, ask which materials, workspace and commands make the job reproducible.
Section 35 of 36
35. Build a validation ladder
Validate paths and manifests, pull pinned images, run a tiny task, test resource limits and failures, verify output upload, then increase scale.
Working checkpoint — resource request: Use the smallest fixture that exercises the full data path. Treat file paths, URLs, image digests and units as scientific inputs: a silent mismatch can run the wrong computation.
For parents, ask who may stage the data and where outputs are allowed to go.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver task documents, manifests, image digests, commands, resource records, task and workflow IDs, logs, outputs, checksums, costs and governance notes.
Working checkpoint — task log: Make each retry a distinct traceable attempt rather than overwriting history. Keep the task document, input manifest, image digests, resources, task ID, states, logs and output checksums together.
For a classroom model, use safe job cards and empty shared folders rather than real data.
Contents · Previous section · Continue to the Science Learning Hub