> For the complete documentation index, see [llms.txt](https://docs.omics.ai/products/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omics.ai/products/workbench/variant-interpreter/reviewing-variants/structural-variants/structural-variant-detail.md).

# Structural variant detail

Selecting a structural variant opens the variant drawer. Its tabs are **Variant**, **Gene**, **Browser**, and **Classification**. This page covers the **Variant** tab, which gathers the evidence for the call into a sequence of cards:

1. **Why this call**
2. **Read Support**
3. **Network** (HiFi Solves)
4. **Variant Summary**
5. **Evidence in this sample**
6. **Consequence**
7. **Clinical evidence**
8. **Predicted effect**
9. **Population frequency**

For the **Gene** tab see [Annotation panels](/products/workbench/variant-interpreter/reviewing-variants/annotation-panels.md#the-gene-tab), for **Browser** see [The genome browser (IGV)](/products/workbench/variant-interpreter/reviewing-variants/genome-browser.md), and for **Classification** see [Classifying variants](/products/workbench/variant-interpreter/classifying-variants.md).

## Why this call

A short digest of the evidence behind the automated classification: **Tool call**, **Population evidence**, **Network**, **Curated overlap**, and **Dosage direction**. Every value is read directly from the record, not predicted. If the record contradicts the classification badge, for example a "pathogenic" call that is common in the population, the card switches to a warning style.

## Read Support

The **Read Support** card draws the SV's junction from the call itself, with the split and discordant reads from the sample's alignments underneath.

The diagram shows:

* the reference sequence around each breakpoint, tinted by chromosome;
* the breakpoints, drawn differently when the caller marks the call as imprecise;
* a shaded band for the caller's breakpoint uncertainty;
* a hatched span where the breakpoints share microhomology;
* an arc linking the breakends (or a caret for an insertion), with markers for the direction each breakend continues;
* a RefSeq gene lane.

Small same-chromosome events are drawn as one continuous window; larger and inter-chromosomal events are drawn as two windows, one per breakend.

The card header shows how many **split / discordant reads** support the call. The card previews a sample of them; when there are more, it tells you how many are shown. Then:

* Click **Explore reads** to see every supporting read.
* If no reads could be drawn, click **Open in IGV** to open the [genome browser](/products/workbench/variant-interpreter/reviewing-variants/genome-browser.md) on the junction instead.

{% hint style="info" %}
Read Support needs aligned reads for the sample, and the junction diagram is available for the GRCh38 reference only. If either is missing, or the record doesn't carry enough information to draw the junction, the card explains why instead of drawing it.
{% endhint %}

### Exploring the supporting reads

**Explore reads** opens a larger view of every read supporting the junction.

1. Use **Sort reads by** to order the reads: **Junction** (default), **MAPQ**, **Clipping**, or **Haplotype**. Sort by **Haplotype** to group reads under **Haplotype 1**, **Haplotype 2**, and **Unphased**. This shows at a glance whether the support comes from one copy or both. Haplotype is unavailable when the reads carry no haplotype tags.
2. Use **Fade below MAPQ** (**Off**, **20**, **30**, or **60**) to de-emphasize low-mapping-quality reads. Faded reads are not removed: low-confidence support is still support.
3. Hover to see the coordinate under the pointer. A dot on a read marks an insertion of 30 bp or more.
4. Click a read (or move through the reads with the arrow keys) to open **Selected read**. This draws the read's own alignment segments along the read, so you can see how it splits across the junction. Choose the axis orientation with **Longest** (default), **Primary**, or **Reverse**.

The legend explains the marks used, including breakpoint, imprecise breakpoint, breakpoint uncertainty, microhomology, and "crossing ribbons mark an inversion".

## Network

Shows the SV's frequency in the **HiFi Solves** network: its allele frequency, total alleles, and the number of samples and organizations carrying it. HiFi Solves is a rare-disease cohort, not a control population, so read it alongside **Population frequency** rather than in place of it.

## Variant Summary

The core fields of the call, from the VCF and AnnotSV. Depending on the record it also shows:

* **Mate breakend** for a translocation (BND), with a button to copy it;
* **Microhomology**: its length and bases;
* **Inserted sequence**: its length and bases.

Genes overlapped by the SV are shown as badges, with genes that have ClinGen dosage-sensitivity evidence listed first and marked in red. Click **All N genes** to see every overlapped gene, ranked by dosage evidence and then by coding overlap.

## Evidence in this sample

How well this sample supports the call: **Genotype**, **Supporting reads**, **Depth**, **Evidence types**, **Spanning**, **Breakpoint precision**, **Quality**, **Filter**, and **Phase set**.

## Consequence

The SV's predicted effect on genome structure, from AnnotSV: **TAD** (click **Show all boundaries** to list the TAD boundaries in the interval), **Breakpoint context**, **Repeats**, **Frameshift**, and **Nonsense-mediated decay**.

## Clinical evidence

Curated clinical knowledge for the region, from ClinGen, OMIM, GenCC, and DDD: **ClinGen haploinsufficiency**, **ClinGen triplosensitivity**, **Pathogenic loss region**, **Pathogenic gain region**, **Associated phenotypes**, **OMIM**, **Inheritance**, **GenCC**, and **DDD**. Where curated regions overlap the SV, click **View N records** to list them, ranked by reciprocal overlap.

## Predicted effect

Pathogenicity predictions: **AnnotSV ACMG class**, **AnnotSV ranking score**, **Ranking criteria**, **StrVCTVRE**, **PhenoGenius**, **Exomiser gene-phenotype**, and **Constraint**.

## Population frequency

How common the SV is in control populations: **gnomAD-SV**, **gnomAD-SV group maximum**, **CoLoRSdb**, and the AnnotSV benign loss and gain maxima.

{% hint style="info" %}
Rarity is judged against control populations (gnomAD-SV and CoLoRSdb). HiFi Solves is a rare-disease cohort, so it's shown separately as a **Network** signal and doesn't count toward rarity.
{% endhint %}

## Matched phenotypes

While a structural variant is open, the **Phenotype** card in the sample panel shows how many of the sample's HPO terms the SV matches, for example "3 of 12 matched". Matched terms are listed first and highlighted; hover a term to see which gene it was matched through.

## How to review an SV in detail

1. Read **Why this call** for the headline evidence, and note any warning.
2. Check **Read Support**. Open **Explore reads** and sort by **Haplotype** if zygosity or phase matters.
3. Review the overlapped genes in **Variant Summary**, starting with the dosage-sensitive genes marked in red.
4. Weigh **Clinical evidence**, **Predicted effect**, and **Population frequency** together.
5. [Classify](/products/workbench/variant-interpreter/classifying-variants.md) the variant.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.omics.ai/products/workbench/variant-interpreter/reviewing-variants/structural-variants/structural-variant-detail.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
