Toward Canonical HELM Representations for Sequence-Level Peptide Registration

Imagine a partner CRO sends you a peptide, encoded in HELM notation, that already sits in your peptide registration database under a different registration ID. Nothing alerts you. The string comparison simply returns “no match,” and a molecule you already have gets treated as brand new. That should be a bug in your software, right?

HELM (Hierarchical Editing Language for Macromolecules) has become a standard way to represent peptides and other biologics computationally, as sequences of monomers that can include non-natural residues, cyclization, branching, and other structural modifications that don’t fit neatly into a small-molecule representation. It was built to make these molecules easy to write down and exchange between software systems. For biologics research teams, that interoperability is the whole point. What it was never built to do is guarantee that a given molecule has only one correct way to be written down. HELM optimizes for interoperability, not canonicality. The gap between those two goals is where a surprising number of practical registration problems live. It is also the root cause of a deep mistrust in relying on HELM itself as a format for registration instead of the full atomistic molecule representation.

Same Molecule, Different HELM Strings

Consider a small cyclic peptide, joined head-to-tail so it has no free ends. Because the ring has no chemically distinguished starting point, you can legitimately write its HELM string starting at any residue, as long as you keep the same direction of travel around the ring:

• PEPTIDE1{G.P.Y.F.L.A}$PEPTIDE1,PEPTIDE1,6:R2-1:R1$$$
• PEPTIDE1{Y.F.L.A.G.P}$PEPTIDE1,PEPTIDE1,6:R2-1:R1$$$

Both strings describe the exact same molecule. Notice, too, that the connection text “6:R2-1:R1” is identical in both, but it closes a different physical bond in each case. Two identical-looking strings, two different bonds, one molecule. That’s the trap: nothing about the notation itself signals that you’re looking at two names for the same thing.

The same kind of ambiguity shows up in larger, more realistic constructs. A lipidated peptide with a fatty-acid branch hanging off a lysine side chain is the general strategy behind several marketed long-acting peptide therapeutics. That branch can be written before or after the main chain, with the connection table listing either attachment point first. Wherever a monomer exposes more than one attachment point, spec-compliant tools can legitimately disagree about which R-group label to assign to a given bond. Even connections that aren’t part of the backbone at all, like a disulfide bridge between two cysteine side chains, have no inherent direction, so the same bridge can be written “residue 4 to residue 2” or “residue 2 to residue 4” with no change in meaning. Four independent sources of non-uniqueness, all fully spec-compliant, all invisible to a naive string comparison.

When the Round Trip Loses Information

A related problem shows up when HELM notation gets converted to an atomistic structure and back. That’s a common step whenever a registration system needs to run structure-based checks. Some details that are explicit in the HELM connection table don’t survive the trip. Which end of a fatty-diacid linker is the free, pharmacologically relevant carboxylate, and which end is consumed by the amide bond, is unambiguously defined in HELM, but a flattened atomistic structure can have that same fragment reattached at the opposite end and still parse as the very same chemistry. Terminal capping details are a similarly common casualty. HELM isn’t incapable of representing this information.

Why This Matters in Practice

None of this is hypothetical. Internal research on monomer library management has already surfaced a recurring theme: practitioners don’t trust HELM-string equality for duplicate detection, precisely because HELM was never designed to be canonical. This is a known limitation of HELM notation itself, not a flaw in any particular tool. This directly affects peptide registration accuracy, since duplicate detection sits at the core of any registration workflow. The common workaround is falling back to structure-based matching. This approach sidesteps the ambiguity problem but reintroduces exactly the scaling and performance issues that sequence-level registration was supposed to solve, since atomistic similarity checks get slower and less usable as sequences get longer. The industry is already paying a cost for the lack of a canonical HELM form.

The practical failure modes are easy to recognize. A CRO-supplied peptide, serialized differently than your in-house version, gets flagged as a new entity, fragmenting assay and batch history across two records for one molecule, a familiar headache for biologics registration teams managing external CRO data. A duplicate search built on an atomistic round trip can manufacture a spurious “novel” hit or missing a genuine duplicate. None of this shows up as a bug. It shows up as a compound that looks new when it isn’t, or two compounds that look the same when they aren’t.

What We’re Building Toward

We don’t think this problem is unsolvable, and we’ve started building toward an answer. Since HELM notation allows more than one valid string per molecule, our current implementation already canonicalizes several of the sources of ambiguity described above: it finds the canonical rotation of head-to-tail cyclic backbones, reorders and renumbers polymer and connection blocks so that branch-versus-main-chain serialization no longer produces different strings, and correctly tie-breaks components that are genuinely graph-symmetric. Round-trip fidelity and a handful of harder representation questions remain open.

We’re presenting this as a first step, not as a final solution to all problems. Small molecules solved this problem decades ago with the canonicalization of SMILES or the use of InChI; peptide sequences deserve the same treatment. A real canonicalization standard for HELM needs community-level agreement on a traversal rule, a consistent convention for ordering connections and branches, and an explicit way to encode stereochemistry created during registration.