eduKateSG · Why Science?
Store sequencing alignments efficiently—and preserve the reference, checksums, indexes and choices needed to decode the evidence
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. CRAM is a binary file format for storing sequencing alignment data with compact, data-aware encodings. GA4GH lists CRAM as current with Active Engagement and lists CRAM v3.0 as the last approved version; the product page’s version table separately shows v3.0 as maintained, in development and draft dated 15 August 2022, so readers should consult the exact specification used. CRAM can use a reference sequence to store differences rather than repeated bases, organises records into containers, slices and blocks, and supports random access by genomic region. GA4GH says CRAM can reduce storage space and costs by roughly 30 to 50 percent, but actual savings depend on data and encoding choices. A smaller file is not automatically lossless, correctly referenced, uncorrupted or scientifically valid. 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: refget and globally identifiable reference sequences; htsget and secure genomic data streaming; GA4GH Data Repository Service and portable data access; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.
Primary and official sources checked on 12 October 2026: Official GA4GH CRAM product page, current product listing; Official CRAM v3 specification; Official SAM, BAM and CRAM specifications repository; 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
CRAM compresses structured alignment records rather than treating the file as an undifferentiated byte stream. Repeated fields can be encoded by data series, records can share a compression header, and related records can be grouped in slices. That organisation lets implementations choose codecs suited to each stream and supports selective decoding. The exact choices belong in the file, not in undocumented operator memory.
Reference-based compression is the central idea. When an aligned read mostly agrees with a reference, CRAM can preserve the differences instead of repeating every reference base. Decoding therefore depends on the correct reference unless relevant bases are embedded or the data are stored without reference differencing. Reference names alone are unsafe; sequence identity and checksums are part of reproducibility.
Containers hold a compression header and one or more slices. A slice has header information plus core and external data blocks, allowing related fields to be compressed separately. Container landmarks and an accompanying index can support random access. These layers are engineering structures, yet they directly affect scientific usability when only a region or subset of data must be retrieved.
CRAM can preserve alignment information losslessly, but the ecosystem also permits choices that discard or transform selected information, such as quality scores, when an operator explicitly chooses them. “CRAM is lossless” is therefore too broad as a claim. The responsible question is which series and tags were preserved, transformed or omitted in this file and workflow.
Validation has several levels: parse the structure, verify block or container checksums where provided, resolve the intended reference, decode records, compare record-level invariants and test indexed access. A file can pass one level and fail another. Long-term archives should rehearse restoration using independent software and a clean reference source rather than trust today’s local cache.
For students, CRAM makes compression concrete. Instead of writing every letter in a repeated sentence, record a shared reference plus the changes. Then ask what happens if the reference is missing or the wrong edition is used. The exercise links Primary Science observation, Secondary Science measurement, mathematics, computing and the habits of reproducible research.
| Stage | Question | Evidence | Responsible output |
|---|---|---|---|
| Encode | Which alignment information must be preserved? | Records, tags, reference identity and preservation choices | A declared CRAM representation |
| Compress | How are related data streams organised? | Containers, slices, blocks and codecs | A smaller structured file |
| Access | Which region or data subset is needed? | Landmarks, index and reference-aware decoding | A bounded record stream |
| Validate | Can another environment recover the same evidence? | Checksums, reference, record comparisons and tests | A reproducible archive |
Inside this guide
1–12 · Foundations and design
- 1. Start with preservation requirements
- 2. Read the product status precisely
- 3. Understand the relationship to SAM and BAM
- 4. Use reference-based differences
- 5. Do not trust a reference name alone
- 6. Understand embedded references
- 7. Handle reference-independent records
- 8. Read the file definition
- 9. Understand containers
- 10. Understand slices
- 11. Separate core and external blocks
- 12. Read the compression header
13–24 · Models and estimation
- 13. Use the preservation map
- 14. Keep auxiliary tags visible
- 15. Treat quality-score choices explicitly
- 16. Check record counts
- 17. Use checksums at the right layer
- 18. Support random access
- 19. Build and validate an index
- 20. Keep coordinate semantics stable
- 21. Measure compression on representative data
- 22. Distinguish speed from size
- 23. Plan for tool compatibility
- 24. Plan long-term reference retrieval
25–36 · Diagnostics and interpretation
- 25. Stream through htsget carefully
- 26. Store through DRS carefully
- 27. Protect sensitive alignments
- 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 CRAM record
- 35. Build a validation ladder
- 36. Finish with a reproducible bundle
Section 1 of 36
1. Start with preservation requirements
Before choosing compression, decide which alignment fields, tags, read names and quality values must survive. Storage savings are meaningful only against an explicit evidence requirement.
Working checkpoint — CRAM: Write the preservation policy and the intended downstream analyses. Keep reference checksums, format and tool versions, preservation choices, codecs, index and validation evidence together.
For a classroom model, compress an invented sequence and test decoding with the wrong reference.
Section 2 of 36
2. Read the product status precisely
GA4GH lists CRAM as current and Active Engagement and names CRAM v3.0 as the last approved version, while its version table labels v3.0 maintained, development and draft dated 15 August 2022.
Working checkpoint — reference sequence: Cite the exact specification file and tool version used. Read every compression ratio beside dataset type, quality information, tags, reference strategy and measured workload.
For future study, connect genomic files to biology, mathematics and storage engineering while checking official pathways separately.
Section 3 of 36
3. Understand the relationship to SAM and BAM
CRAM represents sequencing alignments from the same broader family of record concepts as SAM and BAM, but uses different storage and compression structures. Conversion is not merely renaming a file.
Working checkpoint — container: Compare record counts and required fields across a round trip. Preserve failed checks, conversion logs and excluded records; a readable file is not the complete archive history.
For scientific writing, report the reference, preservation policy, tools and validation results.
Section 4 of 36
4. Use reference-based differences
Mapped reads often resemble the reference, so CRAM can encode differences and alignment features instead of every matching base. This creates efficient storage and an external dependency.
Working checkpoint — slice: Preserve the reference identity beside the file. Separate structural validity and compact storage from reference correctness, evidence preservation and scientific validity.
For students, ask what was stored once as a reference, what differences were recorded and what must be preserved to decode them.
Section 5 of 36
5. Do not trust a reference name alone
Names such as chr1 or GRCh38 can hide assembly patches, alternate sequences or local modifications. Exact sequence identity matters for decoding and interpretation.
Working checkpoint — checksum: Store checksums and a resolvable reference manifest. Treat reference, header and tag identifiers as scientific inputs: a silent mismatch can change decoded records.
For parents, ask whether efficiency choices keep the evidence future learners or researchers may need.
Section 6 of 36
6. Understand embedded references
The specification allows reference bases to be embedded for a slice. Embedded material changes retrieval needs but still requires careful checksum and provenance handling.
Working checkpoint — random access: Document whether references are external, embedded or unnecessary for each slice. Keep reference checksums, format and tool versions, preservation choices, codecs, index and validation evidence together.
For a classroom model, compress an invented sequence and test decoding with the wrong reference.
Section 7 of 36
7. Handle reference-independent records
Unmapped or verbatim-stored sequence data may not need an external reference in the same way as reference-differenced records. Mixed files need record-aware validation.
Working checkpoint — CRAM: Test mapped, placed-unmapped and unplaced-unmapped examples. Read every compression ratio beside dataset type, quality information, tags, reference strategy and measured workload.
For future study, connect genomic files to biology, mathematics and storage engineering while checking official pathways separately.
Section 8 of 36
8. Read the file definition
A CRAM file begins with its format marker and version information and includes a header container before data containers and an end marker.
Working checkpoint — reference sequence: Reject incompatible versions before decoding records. Preserve failed checks, conversion logs and excluded records; a readable file is not the complete archive history.
For scientific writing, report the reference, preservation policy, tools and validation results.
Section 9 of 36
9. Understand containers
A data container groups a compression header with blocks that form one or more slices. The container header carries counts, spans, landmarks and a CRC field in CRAM v3.
Working checkpoint — container: Inspect container boundaries and reported counts. Separate structural validity and compact storage from reference correctness, evidence preservation and scientific validity.
For students, ask what was stored once as a reference, what differences were recorded and what must be preserved to decode them.
Section 10 of 36
10. Understand slices
A slice groups a bounded run of records and begins with a slice header followed by core and external data blocks. It can describe a single reference region, multiple references or unmapped records.
Working checkpoint — slice: Test slice metadata against decoded records. Treat reference, header and tag identifiers as scientific inputs: a silent mismatch can change decoded records.
For parents, ask whether efficiency choices keep the evidence future learners or researchers may need.
Section 11 of 36
11. Separate core and external blocks
CRAM can place selected data series in a core block and others in external blocks. This separation lets codecs and selective access follow data characteristics.
Working checkpoint — checksum: Preserve content IDs and encoding maps when diagnosing a file. Keep reference checksums, format and tool versions, preservation choices, codecs, index and validation evidence together.
For a classroom model, compress an invented sequence and test decoding with the wrong reference.
Section 12 of 36
12. Read the compression header
The compression header contains preservation information, data-series encodings and tag encodings. It tells a decoder how record streams were represented.
Working checkpoint — random access: Archive a human-readable inspection of these maps. Read every compression ratio beside dataset type, quality information, tags, reference strategy and measured workload.
For future study, connect genomic files to biology, mathematics and storage engineering while checking official pathways separately.
Section 13 of 36
13. Use the preservation map
Preservation settings indicate choices such as whether read names are included and how selected values are represented. They are scientific provenance, not only implementation detail.
Working checkpoint — CRAM: Compare settings with the written preservation policy. Preserve failed checks, conversion logs and excluded records; a readable file is not the complete archive history.
For scientific writing, report the reference, preservation policy, tools and validation results.
Section 14 of 36
14. Keep auxiliary tags visible
Alignment tags can carry information needed by downstream methods. A conversion that drops an unfamiliar tag may be technically readable yet analytically incomplete.
Working checkpoint — reference sequence: Inventory required and optional tags before conversion. Separate structural validity and compact storage from reference correctness, evidence preservation and scientific validity.
For students, ask what was stored once as a reference, what differences were recorded and what must be preserved to decode them.
Section 15 of 36
15. Treat quality-score choices explicitly
Quality values can dominate file size and some workflows transform or discard them. Such choices may affect recalibration, variant calling or future reanalysis.
Working checkpoint — container: Label any lossy quality transformation and justify it for the use case. Treat reference, header and tag identifiers as scientific inputs: a silent mismatch can change decoded records.
For parents, ask whether efficiency choices keep the evidence future learners or researchers may need.
Section 16 of 36
16. Check record counts
Counts at file, container and slice levels help reveal truncation, filtering or conversion mistakes. Equal file size is not evidence of equal records.
Working checkpoint — slice: Reconcile counts before and after each operation. Keep reference checksums, format and tool versions, preservation choices, codecs, index and validation evidence together.
For a classroom model, compress an invented sequence and test decoding with the wrong reference.
Section 17 of 36
17. Use checksums at the right layer
CRAM v3 includes CRC checks for structures, and slice headers can carry reference MD5 information. These checks answer different integrity questions.
Working checkpoint — checksum: Verify every available layer and report which checks were absent. Read every compression ratio beside dataset type, quality information, tags, reference strategy and measured workload.
For future study, connect genomic files to biology, mathematics and storage engineering while checking official pathways separately.
Section 18 of 36
18. Support random access
GA4GH highlights random access by genomic region and selective access by data type. Efficient access depends on file organisation, indexes and tools that interpret them consistently.
Working checkpoint — random access: Retrieve known intervals and compare with a sequential scan. Preserve failed checks, conversion logs and excluded records; a readable file is not the complete archive history.
For scientific writing, report the reference, preservation policy, tools and validation results.
Section 19 of 36
19. Build and validate an index
Indexes point clients to candidate containers or slices; they do not prove that the target records decode correctly. A stale index can omit or misdirect retrieval.
Working checkpoint — CRAM: Regenerate or verify the index after file changes. Separate structural validity and compact storage from reference correctness, evidence preservation and scientific validity.
For students, ask what was stored once as a reference, what differences were recorded and what must be preserved to decode them.
Section 20 of 36
20. Keep coordinate semantics stable
Regional access depends on reference identity and coordinate conventions inherited from alignment records. Off-by-one errors can look like missing biology.
Working checkpoint — reference sequence: Test intervals at chromosome starts, ends and single-base boundaries. Treat reference, header and tag identifiers as scientific inputs: a silent mismatch can change decoded records.
For parents, ask whether efficiency choices keep the evidence future learners or researchers may need.
Section 21 of 36
21. Measure compression on representative data
GA4GH reports that CRAM can reduce disk space and storage costs by 30 to 50 percent. Real ratios vary with read type, tags, quality data, reference similarity and codec choices.
Working checkpoint — container: Benchmark representative files and report both bytes and policy. Keep reference checksums, format and tool versions, preservation choices, codecs, index and validation evidence together.
For a classroom model, compress an invented sequence and test decoding with the wrong reference.
Section 22 of 36
22. Distinguish speed from size
A smaller file may reduce transfer while increasing or decreasing CPU work depending on codec, hardware and access pattern. One benchmark cannot answer every workload.
Working checkpoint — slice: Measure sequential read, regional access and conversion separately. Read every compression ratio beside dataset type, quality information, tags, reference strategy and measured workload.
For future study, connect genomic files to biology, mathematics and storage engineering while checking official pathways separately.
Section 23 of 36
23. Plan for tool compatibility
Readers and writers differ in supported CRAM versions, codecs and edge-case behaviour. A file produced successfully by one tool needs independent readback.
Working checkpoint — checksum: Test with at least one separate implementation where practical. Preserve failed checks, conversion logs and excluded records; a readable file is not the complete archive history.
For scientific writing, report the reference, preservation policy, tools and validation results.
Section 24 of 36
24. Plan long-term reference retrieval
An archive that depends on a local reference path is fragile. Reference checksums and services such as refget can make identity and retrieval explicit.
Working checkpoint — random access: Perform a clean-room restore without the original cache. Separate structural validity and compact storage from reference correctness, evidence preservation and scientific validity.
For students, ask what was stored once as a reference, what differences were recorded and what must be preserved to decode them.
Section 25 of 36
25. Stream through htsget carefully
htsget can transport genomic data in bounded streams while CRAM defines a file representation. Streaming, format and authorisation remain separate layers.
Working checkpoint — CRAM: Record requested region, output format, reference and response provenance. Treat reference, header and tag identifiers as scientific inputs: a silent mismatch can change decoded records.
For parents, ask whether efficiency choices keep the evidence future learners or researchers may need.
Section 26 of 36
26. Store through DRS carefully
DRS can identify and provide access methods for a CRAM object and its index. Object identity does not explain preservation choices or reference dependencies.
Working checkpoint — reference sequence: Link the object record to a validation and reference manifest. Keep reference checksums, format and tool versions, preservation choices, codecs, index and validation evidence together.
For a classroom model, compress an invented sequence and test decoding with the wrong reference.
Section 27 of 36
27. Protect sensitive alignments
Compression does not encrypt human genomic data or determine who may read it. Access controls, secure transport and approved encryption remain necessary.
Working checkpoint — container: Threat-model storage, transfer, temporary files and logs. Read every compression ratio beside dataset type, quality information, tags, reference strategy and measured workload.
For future study, connect genomic files to biology, mathematics and storage engineering while checking official pathways separately.
Section 28 of 36
28. Connect to Primary Science
A shared picture plus a list of differences shows why a reference can reduce repeated information. If the picture changes, the difference list becomes ambiguous.
Working checkpoint — slice: Use a simple invented sequence and two clearly labelled editions. Preserve failed checks, conversion logs and excluded records; a readable file is not the complete archive history.
For scientific writing, report the reference, preservation policy, tools and validation results.
Section 29 of 36
29. Connect to Secondary Science
Measurements need units, calibration and raw-evidence preservation. Compression choices similarly determine which future questions the stored alignment can support.
Working checkpoint — checksum: Compare lossless and intentionally transformed fictional records. Separate structural validity and compact storage from reference correctness, evidence preservation and scientific validity.
For students, ask what was stored once as a reference, what differences were recorded and what must be preserved to decode them.
Section 30 of 36
30. Connect to mathematics
Compression ratios, intervals, checksums and indexing connect CRAM to percentages, discrete structures, probability and error detection.
Working checkpoint — random access: Calculate ratio and verify a boundary interval by hand. Treat reference, header and tag identifiers as scientific inputs: a silent mismatch can change decoded records.
For parents, ask whether efficiency choices keep the evidence future learners or researchers may need.
Section 31 of 36
31. Connect to computing
Binary formats, codecs, streaming, random access, hashing and version negotiation show how software engineering becomes laboratory infrastructure.
Working checkpoint — CRAM: Inspect one file with a validator and a regional query tool. Keep reference checksums, format and tool versions, preservation choices, codecs, index and validation evidence together.
For a classroom model, compress an invented sequence and test decoding with the wrong reference.
Section 32 of 36
32. Connect to pathways
CRAM connects genomics, bioinformatics, storage engineering, cloud operations and research data stewardship and can illuminate STEM pathways.
Working checkpoint — reference sequence: Check current official qualifications separately. Read every compression ratio beside dataset type, quality information, tags, reference strategy and measured workload.
For future study, connect genomic files to biology, mathematics and storage engineering while checking official pathways separately.
Section 33 of 36
33. Did you know?
CRAM can separate data series into different blocks, so a decoder may avoid processing every kind of information for every request. The format is structured compression, not just a zipped alignment file.
Working checkpoint — container: Relate selective decoding to the requested analysis. Preserve failed checks, conversion logs and excluded records; a readable file is not the complete archive history.
For scientific writing, report the reference, preservation policy, tools and validation results.
Section 34 of 36
34. Write a reader-ready CRAM record
Name the CRAM specification and writer, source format, reference checksums, preservation and lossy choices, index, validation tools and results.
Working checkpoint — slice: Report storage savings only with the benchmark context. Separate structural validity and compact storage from reference correctness, evidence preservation and scientific validity.
For students, ask what was stored once as a reference, what differences were recorded and what must be preserved to decode them.
Section 35 of 36
35. Build a validation ladder
Parse structure, verify checksums, resolve reference, decode representative slices, compare records, test regional access, then rehearse a clean restore.
Working checkpoint — checksum: Stop at the earliest unexplained mismatch. Treat reference, header and tag identifiers as scientific inputs: a silent mismatch can change decoded records.
For parents, ask whether efficiency choices keep the evidence future learners or researchers may need.
Section 36 of 36
36. Finish with a reproducible bundle
Deliver the CRAM file, index, reference manifest, headers, conversion command, tool versions, preservation policy, checksums, test intervals and validation report.
Working checkpoint — random access: Make future decoding independent of today’s workstation. Keep reference checksums, format and tool versions, preservation choices, codecs, index and validation evidence together.
For a classroom model, compress an invented sequence and test decoding with the wrong reference.
Contents · Previous section · Continue to the Science Learning Hub