Peptide datasets, alignments and reports refer to monomers by symbol. When a monomer changes or disappears, everything built on it is affected. This article explains how the service keeps a history, what it records and what it deliberately leaves out, and why deleting a monomer is reversible.
Every monomer carries a version number
A monomer is created at version 1. The number increases each time a material change replaces its definition, and the state being replaced is archived. The Version column of the Monomers page shows the current number; Version history shows the archived states.
The version number answers a practical question: a peptide whose properties were computed against MeNle version 1 was computed with a hydrogen on the C-terminal attachment point, and one computed against version 2 with the hydroxyl that makes it an acid. Downstream tools can compare the number they recorded with the current one to know whether a recomputation is due.
What counts as a material change
A change is material when it alters what the monomer is in a sequence. Six things do:
- the symbol;
- the polymer type;
- the monomer type;
- the natural analog;
- the structure, compared on its canonical form;
- the attachment points: their labels, their kind, or their cap groups.
Everything else is cosmetic and is not versioned: the name, the author, the aliases, the stored drawing, the audit dates. Redrawing the same molecule from a different SMILES, with different 2D coordinates or a different atom order, is not a change either. The service compares canonical structures, so only a different molecule counts.
This keeps the history meaningful. A log where every regenerated image is a version would bury the one edit that matters, the cap fix, under noise.
Deleting archives, it does not erase
Deleting a monomer removes it from the library and writes its full state to the archive with the reason DELETED. That archived state is the tombstone. It carries the symbol, the classification, the structure, the drawing, the author, and a copy of the organisation-specific data that the deletion cascaded away: the monomer's metadata rows, its aliases and, on a forced deletion, its monomer-set memberships.
An Administrator can then revive the monomer from the Version history. It comes back under its original identifier, so references that stored the identifier resolve again, with the next version number, its original creation date, and its metadata, aliases and memberships restored. See How to Review a Monomer's Version History.
A deletion is refused while the monomer belongs to a monomer set, unless it is forced. The refusal lists the sets, so that a curator removes the monomer from them knowingly. A forced deletion records the memberships in the tombstone so that a revive can put them back.
Two things prevent a revive:
- Its place has been taken. A live monomer now holds the same symbol, the same name or the same structure for that polymer type, or one of its names, its symbol or one of its aliases, has become another monomer's symbol or alias. The service refuses rather than create a collision; rename or remove the newer monomer, or remove the alias, first.
- It is public. Public reference data is maintained through service releases, never through deletion and revival. See Public Monomers.
A deleted monomer is remembered at registration
When you register a monomer whose symbol or structure matches a deleted one, the registration is held:
Registering 'Deg' corresponds to 1 deleted monomer (2504). Nothing was written. An administrator can revive the archived monomer under its original id, or the registration can go ahead once the correspondence has been judged.
The service does not decide for you whether this is the same monomer coming back or a new one that happens to share a name. Ask an Administrator to revive the deleted monomer, which restores it under its original identifier so that data still pointing at it resolves again.
The duplicate rules proper, which refuse rather than hold, apply between live monomers only. See Canonical SMILES and Duplicate Detection.
Who changed it
The Version history records the account that performed the archiving, and the monomer's audit columns record who created it and who last changed it. An edit, an import or a deletion is attributed to the person who made it, whether it was made in the application or through the service interface, which reads the user from the request's token.
System stands for a change no user started, and for every change recorded before the 2026.11.02 release, when the service applied edits and imports without recording the user. For an import of that period, the Import history of the Import monomers page records who uploaded the file.
Related
- How to Review a Monomer's Version History: reading the log and reviving.