• Home
• Resource
• Hi-C Data Analysis Deliverables: From FASTQ Files to Contact Maps and Interpretation

When a Hi-C project fails, it's rarely because the team didn't understand what Hi-C is. It fails because the team didn't agree in advance what "usable" means, what files should be produced, and which QC gates decide whether deeper sequencing will actually buy interpretable biology.

This article is a deliverables-first guide: what you should expect from a standard Hi-C analysis pipeline starting from FASTQ, how to QC each stage, and how to package results so a PI-led team can reproduce and interpret the contact maps (or compare them across samples) without guesswork.

Key takeaway: Define deliverables and QC gates before sequencing. Otherwise you can hit the "planned read depth" and still end up with contact maps that can't support your biological question.

Why analysis deliverables should be defined before sequencing

Sequencing is often the most expensive line item in a Hi-C budget, so it's tempting to treat analysis as a downstream detail. In practice, analysis deliverables determine upstream choices in at least five ways:

1. What "resolution" is even meaningful depends on library complexity and the number of unique valid pairs you expect to retain after filtering. You can't plan resolution from raw reads alone.
2. Replicate design (biological vs technical) affects whether you can report reproducibility metrics and whether multi-sample comparisons are credible.
3. Reference genome quality affects mapping yield, duplicate behavior, and interpretability of trans contacts (especially in assemblies with collapsed repeats or misjoins).
4. Normalization and reporting conventions determine whether a collaborator can compare your matrices to public data or to previous internal datasets.
5. Interpretation outputs (compartments, domains/TADs, loops, SV signals, scaffolding) are not "free add-ons." They require minimum depth, careful filtering choices, and often specific matrix resolutions.

A practical rule: before you sequence, you should be able to answer, in one sentence, what the analysis package will contain. For example:

• "For each sample we will deliver raw FASTQ, mapping + QC summaries, a deduplicated valid-pairs file, multi-resolution matrices in .hic and .mcool, a QC dashboard including cis/trans and distance-decay, and genome-wide compartment and domain tracks. If the project is for assembly scaffolding, we will additionally deliver scaffold FASTA + AGP and a misjoin review with chromosome-scale contact maps."

That sentence forces the right conversations early: what format you need, what you will (and won't) interpret, and what the QC failure modes look like.

Raw data and preprocessing outputs: FASTQ, mapping statistics, valid pairs, duplicate rate

In deliverables conversations, I recommend treating preprocessing as two things: a data product (valid pairs you can reuse) and an audit trail (the counts that explain what was filtered and why).

Most pipelines differ in implementation details, but they converge on the same deliverables categories: raw reads, alignment artifacts, filtered "valid" interactions, and summaries that let you diagnose where yield was lost.

1) Raw deliverables: FASTQ + integrity metadata

At minimum, you should receive:

• The raw FASTQ files (paired-end) and a manifest/checksums.

Some teams also ask for a short "Hi-C contact map interpretation" note at this stage. I'd push that downstream. Early deliverables should prioritize traceability and whether the library is worth turning into matrices.

• Raw FASTQ (paired-end, per lane or merged per sample).
• Checksums (e.g., MD5) and a file manifest.
• A short FASTQ QC summary (read quality, adapter content, and any trimming/filtering applied).

This sounds basic, but it matters for reproducibility and for later reprocessing when a new reference genome or a new filtering strategy becomes relevant.

For a practical overview of how preprocessing outputs are usually structured (pairs files, matrices, and associated reports), see the Bioconductor chapter on Hi-C preprocessing Hi-C pre-processing steps (Orchestrating Hi-C Analysis, Bioconductor).

2) Mapping deliverables: alignment statistics and what "mapping rate" really means in Hi-C

In Hi-C, mapping is not just "% aligned." Each end maps independently, and read pairs can be discarded for multiple reasons: multi-mapping, low MAPQ, chimeric artifacts, and invalid ligation structures.

Your preprocessing deliverables should include:

• Total read pairs and read pairs retained after basic filtering.
• Unique mapping yield (often stratified by MAPQ threshold).
• Intra- vs inter-chromosomal mapping breakdown (early look at cis vs trans, before final filtering).
• Duplication statistics (PCR duplicates or optical duplicates, depending on pipeline).

The point of reporting these numbers is not to hit a universal "good" threshold. It's to identify which stage is limiting your usable contacts and whether additional sequencing will add new information or mostly add duplicates.

A peer-reviewed review that is useful for framing QC deliverables and interpretation is Lafontaine et al.'s discussion of computational processing and QC for Hi-C-type assays in Briefings in Bioinformatics (2019) Lafontaine et al., 2019.

If you need a reference that is more "deliverables and file formats" oriented than a wet-lab-focused methods section, the Bioconductor book chapter on Hi-C preprocessing walks through .pairs and multi-resolution matrix formats.

3) Valid pairs deliverables: what they are and what file formats to expect

After alignment and artifact filtering, pipelines produce a set of "valid" Hi-C contacts, often called valid pairs, allValidPairs, or chimeric pairs. Conceptually, this is a deduplicated list of contacts between genomic loci after excluding obvious artifacts.

Deliverables you should expect:

• A valid-pairs table (commonly in .pairs-like formats or pipeline-specific tabular outputs), ideally compressed.
• A filtering report: counts for categories such as dangling ends, self-ligation, re-ligation, duplicates removed, and the final valid-pair count.

From a deliverables perspective, the valid-pairs file is the most valuable intermediate artifact: it lets you rebuild matrices at different resolutions, test alternative normalization, or rerun downstream callers without rerunning alignment.

4) Duplicate rate and library complexity: deliverables, not just a single number

Hi-C libraries can be very deep, and duplicate behavior is often the first sign that additional sequencing is approaching diminishing returns.

Instead of a single duplicate %, a useful deliverables package includes:

• Duplicate rate after alignment and duplicate marking.
• Unique valid pairs (absolute count).
• A complexity curve or a short note that interprets whether additional sequencing is likely to yield more unique contacts.

Lafontaine et al. (2019) explicitly discusses duplicates as a core QC component and ties duplication behavior to library complexity and interpretability.

Hi-C data analysis deliverables for contact matrix generation and normalization

If you only define one deliverable precisely, make it the matrix package. Everything downstream (QC plots, compartments, domains, loops, and comparisons) depends on it.

Key takeaway: In practice, "Hi-C contact matrix normalization" is not one choice; it's a set of choices (balancing method, distance detrending, binning) that should be recorded as deliverables.

The "matrix stage" is where deliverables often become ambiguous. One lab expects a single 10 kb matrix; another expects multi-resolution .hic plus balanced and observed/expected versions. Without prior agreement, you end up with matrices that are hard to visualize, hard to compare, or missing the exact normalization needed for downstream analysis.

Matrix deliverables to define explicitly

For each sample, define (and receive):

1. Matrix file format(s)

   • Common practical formats are multi-resolution containers that support zooming and efficient visualization.
   • Decide up front what your collaborators use (e.g., Juicebox-style .hic vs cooler-based .mcool).

2. Bin sizes / resolutions delivered

   • A realistic package includes multiple resolutions (for example, 1 Mb for compartments; 100 kb–25 kb for domains; and finer only when depth supports it).
   • The deliverables should include a short note connecting resolution to unique valid pairs, not just "we generated 5 kb matrices."

3. Matrix scope

   • Whole-genome, per chromosome, or a subset.
   • Cis-only vs cis+trans matrices, depending on analysis goals.

4. Normalization state(s)

   • Raw counts (useful for some QC and depth calculations).
   • Balanced matrices (ICE/KR style) for comparability.
   • Observed/expected (O/E) detrending for compartment-style visualization.

ICE, KR, and what "balancing" actually means

Most Hi-C analyses rely on some form of matrix balancing: correcting for biases so that bins have comparable "visibility."

• ICE (Iterative Correction and Eigenvector decomposition) is a canonical balancing approach introduced by Imakaev et al. (2012) Imakaev et al., 2012.
• KR balancing is commonly referenced via the Knight–Ruiz algorithm (2013) Knight & Ruiz, 2013.

From a deliverables standpoint, you want two things:

• The balanced matrix itself.
• The metadata required to reproduce it (software, version, and key parameters).

Observed/expected (O/E): a deliverable for interpretation, not a substitute for QC

Observed/expected transforms reduce the dominance of distance-dependent decay and make broad structural patterns (like compartments) easier to see.

In your deliverables agreement, specify whether you expect:

• Raw matrices only
• Balanced matrices
• Balanced + O/E matrices

…and be explicit about which downstream outputs (compartments, saddle plots, etc.) will be computed from which normalization state.

Contact map QC: cis/trans ratio, distance decay, library complexity, and reproducibility

This is where you stop thinking like a pipeline developer and start thinking like a reviewer: do these contact maps behave like Hi-C, and are they consistent enough to support the claims you want to make?

Teams often ask for "Hi-C QC metrics" as a bullet point; the more useful framing is to agree on the specific plots and tables that will be delivered, and what decision each one informs.

QC deliverables should be designed to answer a simple question: If you changed one upstream choice (more depth, different protocol, better reference genome, different filtering), would interpretability improve?

A QC report that only lists "reads mapped" and "valid pairs" is rarely enough to answer that.

Cis/trans ratio (and why it's still one of the fastest sanity checks)

The cis/trans ratio summarizes whether contacts are enriched within chromosomes relative to between chromosomes. A low cis/trans ratio often reflects more random ligation and noise.

Both practical guidelines and QC reviews discuss cis/trans as a core quality indicator, including the practical Hitchhiker's Guide to Hi-C analysis and the computational QC review by Lafontaine et al. (2019).

Deliverable expectation:

• Report cis/trans at least once per sample (and per replicate if applicable), and show it alongside other QC metrics so it is not over-interpreted.

Distance decay curve: what you should receive and how to read it

Hi-C contact probability decays strongly with genomic distance. A distance-decay plot is useful because it captures global signal properties that don't appear in a single heatmap snapshot.

The Hitchhiker's Guide emphasizes distance-dependent behavior as a foundational property of Hi-C contact maps.

Deliverable expectation:

• A distance-decay curve (often log–log) per sample, and for multi-sample projects, an overlay plot so you can quickly spot outliers.

Library complexity: show whether more sequencing will add information

Hi-C is especially vulnerable to the "more reads, same molecules" problem: additional sequencing that mainly produces duplicates.

Deliverable expectation:

• A complexity curve or a clear statement that interprets the duplicate behavior in terms of expected gain from deeper sequencing.

Reproducibility: include at least one Hi-C-specific concordance metric

If you have replicates, a deliverables package should include a reproducibility assessment that respects the structure of Hi-C matrices.

Two widely cited reproducibility methods are:

• HiCRep, introduced by Yang et al. (Genome Research, 2017), which uses distance-stratified correlation Yang et al., 2017.
• GenomeDISCO, introduced by Ursu et al. (Bioinformatics, 2018), which compares smoothed contact maps via random walks Ursu et al., 2018.

Deliverable expectation:

• A replicate concordance table (per resolution if possible) and a short note explaining what level of agreement is sufficient for the intended downstream calls.

Pro tip: Ask for reproducibility metrics at the same resolutions used for your primary interpretation outputs. A "good" replicate score at 1 Mb does not guarantee reliable loop calls at 5–10 kb.

Genome-wide outputs: compartments, domains, interaction patterns, structural signals

Once matrices and QC are in place, genome-wide interpretation outputs should be packaged as both human-readable figures and machine-readable tracks/tables.

A/B compartments

A/B compartments reflect broad-scale segregation patterns and are often computed from eigenvectors of normalized contact matrices.

For a canonical description of compartment-scale organization in Hi-C, see the original genome-wide Hi-C paper in Science (2009) by Lieberman-Aiden and colleagues Lieberman-Aiden et al., 2009.

Deliverables:

• A compartment eigenvector track per chromosome (bedGraph/bigWig-style, or equivalent track format used by your lab).
• A short note describing how the sign was oriented (e.g., by correlation with GC content or gene density).
• Representative contact maps showing the compartment "plaid" pattern at an appropriate resolution.

Domains / TAD-like structures

Domain calls are sensitive to resolution, normalization, and caller choice. Even when the biological concept is stable, deliverables should make it clear which algorithm and parameters were used.

Deliverables:

• Domain boundary coordinates (BED-like table).
• A set of representative loci plots.
• A methods snippet: bin size, normalization, caller, and parameters.

Loops / focal interaction enrichments

Loop/peak calling is where teams most often over-promise and under-deliver, because it requires high depth and careful multiple-testing control.

Rao et al. (Cell, 2014) remains a canonical reference for kilobase-resolution maps and loop-scale features Rao et al., 2014.

Deliverables:

• Loop list (BEDPE-like table), including score/FDR if available.
• Clear statement of resolution and minimum distance thresholds.
• Representative loop calls visualized in contact maps.

Structural signals (SVs, translocations, rearrangements): be explicit about intent

Teams sometimes expect Hi-C to "discover structural variants" as a free bonus. You can see signatures of rearrangements in contact maps, but deliverables should be explicit about what is being called algorithmically versus what is being flagged for manual review.

Deliverables:

• A curated set of contact map snapshots at suspected breakpoints.
• A conservative interpretive note: what evidence supports the signal, and what orthogonal validation would be needed.

Assembly-support outputs: scaffolding files, misjoin review, chromosome-level maps

Hi-C for genome assembly scaffolding has its own deliverables profile. The question is not "can we call compartments?" It's "can we order and orient contigs correctly, and can we detect misjoins?"

A canonical peer-reviewed reference for graph-aware scaffolding with Hi-C links is SALSA2 (Ghurye et al., 2019) Ghurye et al., 2019.

If scaffolding is your primary goal, spell out the scaffolding-specific package explicitly up front (FASTA + AGP + misjoin review). Treat those as first-class Hi-C scaffolding deliverables, not as a "nice-to-have."

What you should receive for scaffolding projects

Core assembly deliverables:

• Scaffolded assembly FASTA (final sequence).
• AGP file (assembly layout: contig order, orientation, gap structure).

Hi-C support deliverables:

• A chromosome-scale contact map used for scaffolding QC (typically viewable in common Hi-C browsers).
• A misjoin review: a short report identifying suspicious joins with supporting contact-map evidence.

Misjoin review: what makes it credible

A useful misjoin review is conservative:

• It distinguishes "probable misjoin" from "possible misjoin."
• It shows the evidence in the contact map (not just a list of coordinates).
• It notes confounders (centromeres, repeats, collapsed segments).

If the assembly is the primary endpoint, this review often matters more than downstream domain/loop calling.

Multi-sample comparison outputs for cohorts or cell line studies

Comparing samples is where deliverables need the most discipline, because differences can be biological (chromatin remodeling, differentiation) or technical (batch effects, depth, restriction site density differences between assemblies).

Deliverables that enable honest comparisons

For multi-sample projects, ask for:

• A harmonized matrix set: same genome build, same binning scheme, same normalization convention.
• Per-sample QC dashboards plus a cross-sample QC summary (one page that highlights outliers).
• A replicate concordance matrix (HiCRep/GenomeDISCO) when replicates exist.

Differential interaction summaries: report what was compared and at what scale

If the pipeline includes differential contacts or differential compartments/domains, deliverables must state:

• The comparison design (pairwise, group vs group, time series).
• The resolution used.
• The statistical framework at a high level (enough to reproduce results).

Otherwise, differential results are easy to misinterpret.

What should be included in a Hi-C analysis report

A report is not a "pretty PDF." It's the document that allows an external reviewer (or a future you) to understand what was done and what the results mean.

A strong Hi-C report typically includes:

1. Executive summary (1 page)

   • What samples were analyzed, what the intended biological question was, and which outputs are deliverable-ready.

2. Methods and reproducibility block

   • Genome build/version
   • Pipeline/software versions
   • Key parameters (MAPQ thresholds, duplicate handling, bin sizes)

3. QC section with pass/fail gates

   • Valid pairs, duplicates/complexity, cis/trans, distance decay
   • Replicate concordance when applicable
   • A short "interpretation limit" statement (e.g., "loop calling is not supported at this depth")

4. Contact maps and genome-wide outputs

   • Representative heatmaps at multiple scales
   • Compartments/domains/loops (if included), with clear file tables

5. Limitations and next-step recommendations

   • What would improve interpretability (more depth, better reference, additional replicates)
   • What would not help (e.g., deeper sequencing of a low-complexity library)

Data delivery checklist before starting a project

Use this checklist before sequencing and before you accept an analysis plan.

A. Define the deliverables package (files + formats)

• Raw FASTQ (+ checksums + manifest)
• FASTQ QC summary and any trimming/filtering notes
• Mapping statistics (unique mapping yield, MAPQ threshold used)
• Duplicate rate + complexity interpretation
• Valid pairs / .pairs-like contact list + filtering category counts
• Multi-resolution contact matrices (format agreed: .hic, .mcool, or both)
• Normalization states delivered (raw / balanced / O/E)

B. Define QC plots you expect to see

• Cis/trans ratio (per sample; per replicate if applicable)
• Distance-decay curve (per sample + overlay for comparisons)
• Library complexity curve (or equivalent dedup/unique-contact reporting)
• Reproducibility metric(s) when replicates exist (e.g., HiCRep, GenomeDISCO)

C. Define interpretation outputs (only what your data can support)

• Compartment tracks (if included) + sign orientation rule
• Domain/TAD boundaries (if included) + caller + parameters
• Loops/peaks (if included) + depth/resolution prerequisites stated
• Structural signals: what is called vs what is manually flagged

D. Define multi-sample comparison rules

• Same reference genome build
• Same bin sizes and normalization conventions
• Cross-sample QC summary + outlier flags

E. If the project is for assembly scaffolding

• Scaffold FASTA + AGP
• Chromosome-scale contact maps used for curation
• Misjoin review report with visual evidence

---

Author

Dr. Yang H., Senior Scientist at CD Genomics. LinkedIn profile

Next steps (study-design oriented)

If you're planning a Hi-C study and want the deliverables to be publication-usable and comparable across samples, it helps to align the analysis package before any sequencing PO is signed. A practical starting point is to agree on: (i) the valid-pairs deliverable, (ii) the matrix formats/resolutions/normalization states, and (iii) the QC dashboard and reproducibility metrics that decide whether deeper sequencing is worth it.

For RUO projects where you want a standardized handoff, CD Genomics' 3D Genomics services and Hi-C sequencing service are designed around transparent QC reporting and reproducible deliverables, with a concise summary of the QC panel in our standardized 3D genomics QC metrics guide.