Terray Therapeutics: Engineering the Hardware Layer of AI Drug Discovery

There is a version of AI drug discovery that exists mostly in press releases: large language models, virtual screening pipelines, and computational docking studies that promise to replace wet lab work. Terray Therapeutics is not that version. Terray is building physical hardware — chips, instruments, optical systems, fluid handling infrastructure — designed to run billions of miniaturized chemistry experiments simultaneously, generating the kind of empirical dataset that AI models actually need to do useful work.

The company’s core platform is a silicon chip containing millions of sub-nanoliter reaction chambers. Small molecules are loaded into these chambers at scale, each chamber containing a unique compound in contact with a biological target. Optical readout systems image the entire chip surface. Data pipelines ingest the signal and extract binding affinity measurements across the full compound library. The AI sits downstream of all of this, training on datasets that no previous experimental approach could have produced economically.

That description sounds clean. The engineering reality underneath it is not.

A Platform With No Single Engineering Discipline

Most instruments are primarily one thing. A mass spectrometer is primarily analytical chemistry instrumentation with mechanical and electronic subsystems in support. A semiconductor lithography tool is primarily precision optics and motion control. A flow cytometer is primarily photonics and microfluidics.

Terray’s platform is not primarily any one thing. It is, in approximately equal measure, a semiconductor fabrication product, a microfluidics system, a surface chemistry platform, a high-throughput optical imaging instrument, and a data infrastructure problem. Each of these is a full engineering discipline with its own design vocabulary, its own failure modes, and its own body of standards and practice. None of them speaks the other’s language natively.

The chip itself is a silicon substrate, which means wafer fabrication, photolithography, etch processes, surface functionalization chemistry, and yield management — all the concerns of a semiconductor manufacturer. The fluid handling that loads compounds into those chambers is microfluidics: laminar flow regimes, surface tension effects, evaporation control, dead volume minimization. The surface chemistry that keeps molecules in their wells and presents the target protein in a functional orientation is biochemistry, with its own sensitivity to pH, ionic strength, temperature, and contamination. The optical system that images millions of chambers at sufficient resolution and throughput is a precision optics and detector engineering problem. And the data infrastructure that ingests, quality-filters, aligns, and delivers results from a single chip run — which can generate terabytes of raw image data — is a distributed systems and signal processing problem before it is ever an AI problem.

The engineering challenge is not solving each of these problems individually. Each sub-discipline has practitioners who can solve their piece. The challenge is defining and maintaining the requirements that hold all of them together across a shared system boundary, and propagating changes in one domain into their consequences across all the others.

The Hardware-Software Interface as a Requirements Problem

Drug discovery platforms live or die on what they deliver to the scientist. For Terray, that deliverable is a measurement: the binding affinity of a given compound to a given target, expressed with some quantified uncertainty, derived from optical signal acquired from a specific chamber on a specific chip in a specific instrument run.

That measurement is the system’s output. Everything upstream — chip fabrication, surface chemistry, fluid loading, optical acquisition, image processing, signal extraction — is in service of producing it reliably and at scale. Everything downstream — the AI model, the medicinal chemistry interpretation, the hit-to-lead optimization workflow — depends on trusting it.

The interface between the hardware platform and the computational biology software is, at its core, a data contract. It specifies what data the instrument produces, in what format, with what associated metadata, at what quality thresholds, and under what conditions a run should be flagged for exclusion. This contract has to exist as a requirements artifact before either side can build toward it coherently.

In practice, this is where many instrument development programs of this type break down. Hardware teams define their output by what their subsystems can produce. Software teams define their input by what their models were trained on or what their algorithms assume. The interface is negotiated informally, late, and often painfully — because changing a data format or a quality metric after the model is trained is expensive, and changing a chip geometry or an imaging protocol after the fabrication process is locked is expensive in a different way.

The requirement that this interface be stable is not a software requirement. It is not a hardware requirement. It is a system requirement, and it has to be owned at a level of the organization that can see across both. The engineering discipline to maintain that system-level requirement — through subsystem changes, through model retraining cycles, through chip generation transitions — is requirements management in the most practical sense of the term.

V&V Without a Predecessor

Every instrument development program faces validation challenges. Terray’s are unusual in a specific way: there is no predecessor instrument that performs the same function at the same scale. Validation normally proceeds by comparison — does this instrument agree with the reference method within acceptable tolerance? When the instrument is the first of its kind, that comparison is not available.

This forces a different approach. Terray cannot validate the platform by showing that it agrees with prior art. It must validate the platform by showing that it is self-consistent, that its outputs are interpretable, and that the measurements it produces are predictive of biological outcomes that can be independently confirmed.

Self-consistency validation looks at whether replicate chambers containing the same compound and target produce the same signal, whether the same chip run twice produces the same result, whether chips from different fabrication lots produce equivalent results under matched conditions. This is straightforward in principle and technically demanding in practice. Chamber-to-chamber variation is a function of the fabrication process uniformity, the surface chemistry deposition uniformity, and the optical system’s ability to normalize for illumination and detection variation across a wide field of view.

Interpretability validation looks at whether the signals produced by the instrument map onto known biochemistry. Control compounds with established binding affinities — measured by orthogonal methods in prior literature — should produce signals in the expected rank order and within a calibrated range. If the top binders in a well-characterized target-compound system produce the top signals in the chip assay, that is evidence that the measurement is connected to the biology it is supposed to represent.

Predictive validity — the hardest test — looks at whether compounds identified as hits by the platform actually behave as hits in downstream assays and eventually in animal models and clinical settings. This validation loop is long, expensive, and cannot be closed during instrument development. It becomes available only as the platform is used over time and its predictions can be compared against biological outcomes that accumulate in the pipeline.

The consequence is that Terray’s V&V strategy is necessarily staged and evolving. Instrument release cannot wait for predictive validity data that will only accumulate over years. The validation package that supports initial deployment has to be honest about what it establishes — self-consistency and interpretability — and what it does not yet establish — long-range predictive validity. That distinction matters for how the instrument’s output is interpreted and communicated to downstream users.

Building a V&V strategy this way requires that requirements be written with testability as a first-order property. A requirement that cannot be tested within the available validation window is a liability, because it will either be dropped or remain unverified. The discipline to write requirements that are both scientifically meaningful and practically testable is harder than it sounds when the system has no predecessor to copy from.

Bidirectional Pressure Between Hardware and AI

The AI component of Terray’s platform is not a layer added on top of the instrument. It is a design constraint on the instrument, and the instrument is a design constraint on the AI. This bidirectional dependency is one of the more interesting requirements challenges in the system.

On the hardware-shapes-AI side: the chip geometry determines the compounds per chip, the compounds per experiment, and the statistical structure of the dataset. The optical system determines the signal-to-noise ratio per chamber, which sets the floor on the binding affinity resolution the model can learn from. The throughput of the platform determines how quickly the training dataset grows and how diverse it can be across target families and chemical space. When a hardware team makes a decision — increase chamber density, change the readout chemistry, modify the image acquisition protocol — they are making a decision about the training data distribution that the AI team will work with, whether they know it or not.

On the AI-shapes-hardware side: as models mature and their requirements become better understood, they feed back into hardware design. A model that is sensitive to batch effects will push the hardware team to tighten run-to-run reproducibility specifications. A model that can exploit spatial patterns across the chip surface may create new requirements on chip registration accuracy. A model that performs poorly when coverage of a chemical scaffold is sparse may create requirements on library composition that flow back into the compound loading system design.

This feedback loop does not run on a software development cadence. It runs on a hardware development cadence, which is measured in months and fabrication generations, not sprint cycles. Managing it requires a requirements framework that makes the dependencies visible, tracks the rationale behind decisions made at the interface, and gives both teams a shared artifact they can reason from rather than separate documents that diverge over time.

What Modern Requirements Infrastructure Makes Possible

The complexity of Terray’s platform — multiple engineering domains, a hardware-software interface that must be maintained over years, a V&V strategy that evolves as the platform matures, bidirectional dependencies between the instrument and the AI — is exactly the scenario where traditional document-based requirements management breaks down most visibly.

A requirement buried in a chip design specification document has no automated connection to the surface chemistry specification it constrains, or the optical system specification that constrains it in turn, or the data format specification that the imaging team is building toward. When the chip team changes a chamber geometry to improve fill yield, the downstream consequences of that change — on the optical point spread function, on the image processing pipeline, on the AI training data distribution — are invisible unless someone already knows to look for them and has the time to chase them manually.

The engineering teams building instruments at this level of cross-domain complexity are increasingly adopting graph-based requirements models rather than document-based ones. A graph-based model represents requirements, design decisions, test cases, and their relationships as nodes and edges rather than as paragraphs in siloed documents. A change to a node propagates visibly to all the nodes it is connected to, making the downstream impact reviewable rather than invisible.

Tools like Flow Engineering, built explicitly for hardware and systems teams managing this kind of cross-domain complexity, implement requirements as a connected graph rather than a document set. This means a requirement on chamber optical uniformity can be explicitly linked to the chip fabrication specification it derives from, the imaging calibration procedure it gates, and the AI data quality threshold it ultimately supports. Change one node and the affected nodes surface immediately. The traceability is structural, not manual.

For a company like Terray, where the consequence of an untraced requirement change is not a delayed software release but potentially years of invalidated training data or a requalification event on a regulated instrument, that structural traceability is not a productivity feature. It is a risk management feature.

An Honest Assessment

Terray is doing something genuinely hard. The platform they are building does not have a template. The engineering disciplines it integrates do not have a shared vocabulary or a shared standards body that tells them how to talk to each other. The validation strategy they must pursue is incomplete by definition at the time of initial deployment, and it will stay incomplete until a clinical pipeline matures enough to provide retrospective confirmation.

The companies that succeed in this space will not necessarily be the ones with the best chip fabrication process or the best AI model in isolation. They will be the ones that can manage the integration — the requirements that span disciplines, the interfaces that must stay stable while subsystems evolve, the V&V strategies that are honest about what they establish and what they do not.

That is an engineering management problem as much as it is a technical problem. And it is one of the more interesting ones currently running anywhere in the instrumentation industry.