Compound Registration and Screening Software Problems: The 6 That Corrupt Structure Activity Data, and How to Avoid Them

Why does registration get scoped as a catalogue of structures?

Because from outside the laboratory it looks like one. Structures go in, identifiers come out, people search them. Any competent development team can build that in a few sprints, and the result will be wrong in a way that only becomes visible once several thousand compounds are in it.

What makes registration hard is that identity is a policy, not a calculation. Before you can decide whether an incoming structure is new, somebody has to decide how tautomers are handled, whether charges and salts are stripped, how stereochemistry is perceived, what happens with isotopes, and whether a defined single enantiomer and its racemate are the same registration or two. Those decisions produce the identity key, and an international chemical identifier such as InChI is a reasonable basis for that key, but the standardisation choices in front of it determine everything downstream.

The organisational half is harder still. A chemist submits and the system reports a duplicate. Sometimes that is correct and valuable. Sometimes it is a false match created by a normalisation rule the chemist disagrees with, and if there is no documented override path with a reviewer, the chemist keeps a spreadsheet instead and your collection quietly develops a shadow.

So the first release should not be a catalogue. It should be the policy written down, versioned, implemented, and a registration workflow with duplicate detection, reviewed override and corrections handled as versioned identity. Get one person authorised to decide registration policy before anyone writes code. Projects that try to reach consensus across every chemist take a quarter longer and land somewhere nobody defends.

What goes wrong when you re-register a legacy collection?

This is the largest hidden cost in the category and the most common reason a project stalls.

Twenty years of compounds were registered under conventions that changed several times, often informally. Push them through one modern normalisation policy and thousands of conflicts appear: pairs that were separate registrations and now collapse to one, single registrations that now split, stereochemistry that was undefined and is now perceived differently, salts recorded as parents. Each conflict is a chemistry judgement, and only a chemist can make it. There is no import script that removes this.

Three things keep it survivable. First, do not migrate everything on day one. Move the active collection and recent assay data, keep the legacy system available read only, and re-register historical compounds in waves as programmes need them. Second, treat adjudication as scheduled staffed work with a named owner and a weekly rate you can actually sustain, not as a data cleanup sprint. Third, never let a migration silently change what a published or reported result referred to. If a historical registration collapses into another, the old identifier must remain resolvable and must point somewhere honest, because it appears in reports, patents and papers that you cannot edit.

The related trap is assay history. Results carry the assay protocol version that produced them, and legacy data often does not record which version was in force. Import it with an explicit unknown rather than assuming the current one, because a silent assumption becomes a comparison across incompatible protocols and nobody will spot it in a table.

Why do instrument and liquid handler feeds break after launch?

The reader parser is the integration everyone expects to break, and it does, but predictably: a firmware update changes a header, an export template gets edited by a scientist to add a column, and the parser silently mismaps. The defence is validation rather than tolerance. Check the plate dimensions, the expected control positions and the value ranges on every file, reject anything that does not match with a clear message, and never let a parser guess. A file that fails loudly costs an hour. A file that parses wrongly costs a series.

The liquid handler is the integration people forget, and it matters more. The plate map must come from what the handler actually did rather than from what a scientist intended, because those two diverge whenever a tip fails, a source well runs dry or a run is repeated on a different layout. If your system takes the intended map, then one shifted row turns every result on that plate into a confident lie. Ingest the handler's own output, reconcile it against the intended layout, and surface differences as exceptions.

The third is the electronic lab notebook, and it breaks on ownership rather than transport. If both the notebook and the registration system believe they own the compound record, they diverge within a month. Decide which one is authoritative for identity, make the other reference it, and never synchronise both directions on the same field. The same rule applies to inventory and ordering systems: one owner per fact.

What happens when assay versioning and audit trail are not covered?

Two gaps sit outside the obvious scope and both damage the data rather than the software.

Assay definitions change. A protocol is amended, a cell line is replaced, a reference compound shifts, a detection method is swapped. If results do not carry the protocol version that produced them, a chart plotting three years of a single assay is comparing measurements that are not comparable, and the trend it shows may be an artefact of a protocol change. Version the assay, stamp the version on every result, and make any view that spans a version boundary say so rather than smoothing over it. The same applies to curve fitting: the rules that decide when a fit is not reportable belong in the system with a version, not in one scientist's judgement applied inconsistently.

The audit trail is the second. Registration data becomes the memory of the research organisation and it is read in invention records, in due diligence and in data integrity questions. Every structure correction, every override of a duplicate warning, every manual result edit and every batch reassignment needs the person, the timestamp and the reason, stored append only. Corrections in particular must be versioned rather than overwritten, because a structure proven wrong after two years of assay data has to be correctable without orphaning that data or silently changing what earlier reports meant. That is the single design decision most often deferred and least possible to retrofit.

The third routinely uncovered gap is access control across projects. Collaborations, partnered programmes and confidential series all need selective visibility, and bolting that on after the query layer exists usually means rewriting the query layer.

Should you build custom or configure what you already own?

If you are under roughly fifteen scientists working on small molecules, buy CDD Vault. It is well built, inexpensive relative to the category, and a custom build at that size is a distraction from making compounds. If your entity model matches theirs reasonably well, Dotmatics has real depth across registration, assay data and querying, and Benchling is strong where biologics entity modelling is central. Revvity Signals and Schrodinger LiveDesign both bring capable analysis layers on top. These are serious products with real chemistry behind them, and adopting one is the right decision far more often than a vendor selling custom development will admit.

Configure before you build in one common case. Teams frequently blame a product for a problem that is actually an unwritten registration policy, and no software will resolve a disagreement about whether a racemate and its enantiomer are the same registration. Write the policy first. Sometimes the product then fits.

Build when two or more of these are true. Your registration conventions carry decades of history and adopting a vendor's rules would invalidate historical identity. You work across modalities that no single product models properly, meaning conjugates with linker, payload and drug to antibody ratio, peptides with non natural residues, oligonucleotides with modified backbones, or strains and cell lines as first class entities. Your screening cascade has assay specific normalisation and reportability rules living in one scientist's spreadsheet. Per seat licensing has pushed half your organisation back into Excel. Or query performance on the full collection is bad enough that chemists have stopped asking questions, which is the most expensive failure here and the hardest to see because it produces no complaints.

How do hidden costs get into the quote?

Legacy re-registration is the first and largest, and it is chemist time rather than engineering time, which is why it rarely appears in a development quote at all.

Modality count is the second. Each additional entity type is a data model, a registration rule set and a user interface, not a field on a form. A quote for compound registration is priced for small molecules unless it says otherwise.

Instrument parsers are the third, and the trap is the plural. A line reading instrument integration covers one reader, and every additional model, and sometimes every additional export template, is separate work with its own validation.

Substructure search performance is the fourth, because acceptable response times at collection scale need fingerprint screening and a proper chemical index rather than a filter over a table, and retrofitting that means changing the storage layer. Notebook and inventory integration is the fifth. And the sixth is your own people: agreeing the registration policy across chemists who have held different conventions for years is the item that most often sets the schedule, and it belongs to you rather than to any developer.

What separates a build that works from one that fails here?

Appoint one registration policy owner with authority to decide, and write the policy down before code starts. Organisations that do this move dramatically faster than those seeking consensus, and the written policy is also the specification.

Make the parent to batch to sample to well chain visible on one screen from the first release. When a chemist questions a number six months later, they should be able to trace it from the table back to the specific vial, the specific plate well and the raw reading without asking anyone. That single capability is what most spreadsheet based organisations are actually paying for, and it is what stops bad lots from quietly discrediting a series.

Commit to a search response time at your real collection size before you sign, and have the developer demonstrate it on representative data rather than on a sample. Chemists who wait stop asking, and a query nobody runs is a feature that does not exist.

Validate every incoming file rather than tolerating it. Reject on unexpected plate dimensions, missing controls or out of range values, with a message a scientist can act on. Silent tolerance is how one shifted row becomes a year of misdirection.

Finally, settle ownership in writing before kickoff: the repository, the infrastructure accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit. A registration system becomes the long term memory of your research organisation, and that memory cannot sit inside a vendor relationship you might one day want to end.