Where Domain Expertise Meets Engineering
People can sit in the same meeting, use the same words, and still be solving different problems.
When a chemist asks for "compounds similar to this one," a software engineer may assume structural similarity. The chemist, however, may mean similar reactivity or process behavior. Different scaffolds can generate similar by-products under the same conditions, while two structurally similar compounds may need to be handled very differently in practice.
This gap is not always resolved by scheduling more meetings. Both sides may believe their language is clear, so the misalignment only becomes visible after implementation.
It is the moment when a chemist reviews the model and says, "That is not the question we were trying to answer."
Requirements Documents Are Necessary, but Not Always Sufficient
A common development process is for domain experts to document requirements and hand them to engineers for implementation. It creates clear roles and makes progress easier to manage. But the context required to interpret chemical data does not always fit into an initial requirements document.
A document can define the prediction target, scope, and performance criteria. It may not capture the judgments that only emerge when the source data is examined directly.
“This measurement is not comparable under these conditions.”
“The data must be interpreted differently before and after the instrument change.”
“We first need to determine whether this low-yield batch reflects a chemical failure, an instrument issue, or a recording problem.”
Failed experiments can also be valuable training signals. The challenge is to distinguish a chemically meaningful failure from instrument error, missing records, or an operational issue. Without that distinction, a model may learn the wrong relationship.
Deciding whether data should be used is therefore more than a requirements question; it is a domain judgment. That judgment is captured more accurately when domain experts and engineers review the data together.
Reducing the Translation Layer
A study describing Novo Nordisk's ontology-based data management approach identifies data stewardship as essential to coordination among research scientists, data scientists, and semantic experts.
Structuring chemical data is rarely the work of one discipline. Teams must understand the meaning of an experiment, represent it in a data model, and implement that model in a system that people can actually use.
At Alche, we address this by lowering the boundaries between roles. People trained in chemical engineering contribute to model design, while researchers with experience in molecular dynamics help shape the data architecture. The translation of chemical knowledge into a data model happens within one collaborative workflow instead of through a series of disconnected handoffs.
The point is not simply to say that communication matters. It is to reduce the number of translation steps where context can be lost.
How We Work at Alche
We Review Source Data Together
We do not begin with a completed requirements document alone. People who understand the chemistry and people who build the system examine the source data on the same screen. Exceptions, conditions, and differences in recording practice often become visible only at this stage. Designing a structure that can be used in practice requires understanding not only the shape of the data, but also how it was produced.
We Learn to Read One Another's Language
A chemist reads the definition of a data model, and an engineer reads reaction schemes and analytical results. No one needs to replace the other's expertise. But each person needs to understand which details affect interpretation and where another question should be asked. Shared literacy helps the team find those questions earlier.
We Make Uncertainty Explicit
A chemist must be able to say, "The current evidence is not enough to make a confident call." An engineer must be able to say, "This dataset cannot answer that question." If uncertainty is stored as certainty, predictions built on top of it will be difficult to defend. At Alche, distinguishing what is known from what remains uncertain matters more than making uncertainty disappear.
What We Look for in People
We do not expect everyone to understand chemistry and AI at the same depth from day one. We do look for a willingness to learn the language outside one's own discipline, a habit of asking questions from data and evidence, and the ability to state clearly where one's knowledge ends.
The point where domain expertise meets engineering is not simply where two bodies of knowledge are combined. It is where different perspectives are aligned around the same problem. Alche is building that connection into both our products and the way we work.