---
title: "Canonical SMILES and Duplicate Detection"
slug: "canonical-smiles-and-duplicate-detection"
status: "update"
updated: 2026-11-03T16:06:47Z
published: 2026-11-03T16:06:47Z
canonical: "docs.discngine.com/canonical-smiles-and-duplicate-detection"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.discngine.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Canonical SMILES and Duplicate Detection

The same molecule can be written in countless ways. This article explains how the service decides that two monomers are the same structure, what that decision does and does not take into account, and why a missing stereocentre is the most common cause of an unexpected *duplicate* error.

## One molecule, many SMILES

`C[C@H](N[*:1])C([*:2])=O`, `[*:1]N[C@@H](C)C(=O)[*:2]` and `O=C([*:2])[C@@H](C)N[*:1]` are three spellings of L-alanine as a residue. A library that compared text would register three monomers. A library that compared nothing would let a curator register alanine under a new symbol by mistake, and every alignment would then see two different residues where there is one.

The service takes a middle path. On every write, it converts the structure to a **canonical isomeric SMILES**: a single spelling that a given molecule always produces, whatever the input order, coordinates or notation. That string is the monomer's **canonical key**. It is shown in **Version history** as **Canonical key**, and it is what duplicate detection compares.

## What the canonical key keeps and what it drops

The key keeps everything that makes a molecule a different molecule:

- the connectivity and bond orders;
- the elements, charges and isotopes;
- **tetrahedral and double-bond stereochemistry** written with `@`, `@@`, `/` and `\`.

A double bond written without `/` or `\` is kept as **undefined**: cis and/or trans. It is a key of its own, so `[*:2]C=C[*:1]`, `[*:2]/C=C/[*:1]` (trans) and `[*:2]\C=C/[*:1]` (cis) are three monomers.

It normalises everything that is only presentation:

- atom order and ring-closure numbering;
- 2D coordinates;
- the notation of attachment points: `[*:1]`, a CXSMILES `_R1` label and a folded `[H:1]` all become the same dummy atom;
- the other CXSMILES extensions, such as coordinates or atom labels.

**Enhanced stereo groups are kept.** A centre declared racemic (`&1`) or unknown (`or1`) is written at the end of the key as a block on the canonical atom numbering, so the racemate, the unknown and the pure enantiomer drawn the same way are three keys and three monomers. The mirror drawing of a racemate gives the same key as the racemate, because an *and* group says "either configuration" whichever wedge it is drawn on, and the same holds for an unknown. Two monomers that share a drawing with an *or* group are told apart by their **isomer label**, which is part of the uniqueness rule next to the key. See [Enhanced Stereochemistry](/public/docs/enhanced-stereochemistry).

## The duplicate rules

When a monomer is created or updated, three checks run against the **live** monomers of the same polymer type. A match with a **deleted** monomer is handled separately: the registration is held until an administrator revives the deleted monomer or the correspondence is judged. See [Versioning and Deletion](/public/docs/monomer-versioning-and-deletion).

| Check | Scope | Error |
| --- | --- | --- |
| Same canonical key as another live monomer | Your organisation and the public library | *Monomer with this structure is already registered: meG. If you expected a distinct structure, verify your input carries full stereochemistry …* |
| Same symbol as a public monomer | Public layer | *Cannot modify protected public monomer 'Nva' (public seed data)* |
| Same symbol as one of your monomers, on creation | Your organisation | *Monomer with this symbol is already registered: MeA* |
| Same symbol as an alias | Your organisation and the public library | *"R" is already an alias of monomer r.* |

The symbol rule within your own organisation is handled differently by each entry point. The form refuses to create a second monomer with an existing symbol. A bulk import treats a matching symbol as **the same monomer being updated**, so a file can be re-imported to correct a library. See [How to Import Monomers in Bulk](/public/docs/how-to-import-monomers-in-bulk).

The name is also unique within a polymer type of your organisation, so two monomers cannot share a full name even with distinct symbols.

## Why "duplicate" usually means "missing stereo"

The error most curators meet is a duplicate structure they did not expect. In almost every case, the new SMILES has no stereo tag on a centre that the existing monomer defines, or the reverse.

Suppose `Nle` is registered as `CCCC[C@H](N[*:1])C([*:2])=O` and a colleague tries to register D-norleucine as `CCCCC(N[*:1])C([*:2])=O`. The second SMILES has no `@`, so it describes the racemate, and the racemate is a different key from the L form: no collision, and a wrong monomer is now in the library. Later, someone registers the D form properly as `CCCC[C@@H](N[*:1])C([*:2])=O`: still no collision. The library holds L, D and racemic norleucine under three symbols, and only one of them was intended.

Now the reverse. A residue was registered without its stereo tag, and the curator re-registers the L form under a new symbol. The keys differ, so it goes through, and the racemic monomer stays behind as a trap. The right move is to **edit** the existing monomer, not to register a second one.

The duplicate message says as much: *If you expected a distinct structure, verify your input carries full stereochemistry (some molfiles omit stereocenters, e.g. sulfoxide R/S)*. Sulfoxides are the classic case: many drawing tools do not write the sulfur stereocentre at all, so the R and S sulfoxides of a residue produce one key.

## Attachment points and caps in the key

The dummy atoms are part of the key, so a residue with two attachment points and the same residue with three are different monomers. The **cap groups** are not in the key: they live with the attachment point definition, and a change of cap is a material change tracked by versioning rather than a duplicate matter. See [Attachment Points and CAP Groups](/public/docs/attachment-points-and-cap-groups).

## Practical rules

- Write `/` and `\` on every double bond whose geometry you know. Leave them out only for a genuine cis/trans mixture or an unknown geometry.
- Write full stereochemistry on every centre you know. Use `X`-style unknowns only when the centre is genuinely undefined.
- Declare a single enantiomer as absolute. Use an *and* group for a racemate and an *or* group for a fraction whose configuration is not yet known, so that the key tells them apart; see [Enhanced Stereochemistry](/public/docs/enhanced-stereochemistry).
- When you get a duplicate error, open the existing monomer named in the message and compare the two drawings before doing anything else. Nine times out of ten the fix is to edit it, not to register another.
- When the two drawings are the same molecule and only the symbol differs, add your symbol to the existing monomer as an **alias**: sequences written with either name then resolve to it. A bulk import can do it for every such row with the option **Register a known structure as an alias**. See [Monomer Aliases](/public/docs/monomer-aliases).
- Prefer the public monomer when it exists. Your sequences stay comparable with everyone else's.

## Related

- [Versioning and Deletion](/public/docs/monomer-versioning-and-deletion): what happens to the key when a monomer is edited.
- [Enhanced Stereochemistry](/public/docs/enhanced-stereochemistry): racemic and unknown centres, the isomer label, and how a resolved monomer stays linked to its unknown.