Every generative protein design tool, including Proteinvue, asks you to specify what you are optimizing for before generating candidates. The term used for this varies: fitness function, objective function, optimization target. We use "fitness objective" as a shorthand that covers all of these. What it means in practice, and why getting it wrong is more consequential than any model limitation, is what this piece is about.
The Deceptively Simple Question
What property do you want to improve? That sounds like an easy question. In practice, protein engineering projects consistently underspecify the answer in ways that create problems downstream.
The most common underspecification is using a proxy assay output as if it were the actual objective. A team says they want to improve enzyme activity, but they measure activity using a fluorescent substrate analog that is three chemical steps removed from the real substrate. The generative model is told to maximize the fluorescent assay readout, and it does. Then the top candidates get tested on the actual process substrate and show no improvement, or worse, show reduced activity.
This is not a failure of the model. The model did what it was asked to do: optimize for the specified fitness readout. The failure was in the specification. The proxy and the real objective were not as correlated as the team assumed.
Single Scalar vs. Multi-Constraint Objectives
The fitness objective for most protein engineering projects is not a single scalar. It is a set of constraints and preferences across multiple properties, some of which are in tension with each other.
For a therapeutic antibody engineering project, the objective might include binding affinity to the target, reduced binding to off-target proteins, stability in human serum at physiological temperature, expression yield in CHO cells above a defined threshold, and low predicted immunogenicity. These are five separate constraints, and improving any one of them can cost you on another. A generative model that optimizes only for binding affinity will find excellent binders that may fail every other criterion.
For an industrial enzyme campaign, the constraints are typically simpler in number but still plural. Activity on the target substrate above a process-relevant threshold. Thermostability sufficient for process operating temperature. Expression yield in the production host. Optionally, retained or adjusted selectivity if the enzyme acts on a structurally similar molecule you do not want it to modify.
Getting the fitness objective right means being explicit about which constraints are hard limits (the candidate must meet these or it fails) versus soft preferences (we would like to improve these, but the magnitude of improvement is flexible). When all constraints are treated as soft preferences, the optimization can produce candidates that are marginally acceptable on all criteria without being good enough on any of them to advance a project.
The Lexicographic Trap
One common failure mode in multi-objective specification is what we think of as the lexicographic trap. The team lists all the properties they care about and ranks them in priority order, which seems reasonable. But then the optimization treats high-priority properties as strict filters rather than quantitative objectives, collapsing the problem to a smaller version of itself.
For example: first, the candidate must be thermostable (Tm above 58C). Second, among thermostable candidates, it should have maximum activity. In practice, if you apply the Tm threshold as a hard binary filter before optimizing for activity, you may be discarding candidates that are at Tm of 56C but have dramatically higher activity, and where a single additional mutation would push Tm above 58C while retaining most of the activity gain.
A Pareto-front approach, which generates the full set of non-dominated candidates across the two objectives, would surface those candidates. The lexicographic approach throws them away before you can see them. Whether that is the right call depends entirely on whether 58C is a hard physical constraint of the process (perhaps it is the minimum operating temperature) or a guideline derived from the original wild-type stability.
When we set up a design campaign, one of the questions we ask is: which of your constraints are genuinely hard limits determined by physical or regulatory requirements, and which are inherited from the wild type that you are treating as a floor by default? Those are different situations, and they require different formulations of the fitness objective.
Translating Biological Goals into Computable Signals
Generative models optimize against quantitative signals: numbers that can be predicted from a sequence. Translating a biological goal into a computable signal requires a chain of assumptions, and each link in that chain is a potential source of misalignment between what you optimize and what you want.
Consider thermostability. The biological goal is "the protein should not unfold during the process." The typical computable proxy is Tm, melting temperature, measured by differential scanning fluorimetry or calorimetry. Predicted Tm from sequence is a further proxy. Each step in that chain introduces noise and potential bias. Predicted Tm from a sequence model trained on small globular proteins may systematically under- or over-estimate stability for elongated proteins, membrane proteins, or proteins with large disordered regions.
This does not mean you should not use predicted Tm as part of the fitness objective. It means you should know where the prediction comes from, what its accuracy envelope looks like for your protein class, and what confirmatory experiments you will run to validate that optimizing the proxy actually moved the real property in the right direction.
Fitness Objectives as Hypotheses
This is the framing that changes how protein engineers relate to the fitness objective definition step. Your fitness objective is not a fixed specification to hand to a model and receive results from. It is a hypothesis about what predicts success in your downstream application.
The hypothesis is that improving the specified measurable property will improve the practical outcome you care about. That hypothesis can be wrong, and discovering it is wrong is genuinely useful scientific information. But you can only learn from the failure if you specified the objective clearly enough to diagnose the misalignment between the proxy and the real outcome.
When a round of candidates performs poorly in the final assay despite ranking well on the fitness objective, the diagnostic question is: is the model bad at predicting the fitness objective, or was the fitness objective a poor proxy for the real goal? These are different problems with different solutions. The first is a model accuracy problem; the second is a specification problem. Conflating them leads to iterating on model improvements when the real issue is objective formulation.
How We Handle Objective Specification in Practice
When a new design campaign starts, we run an objective specification session before any computational work begins. The output of that session is a written statement of the fitness objective with four components: the primary activity metric and how it is measured, the constraint properties with explicit thresholds and whether each threshold is hard or soft, the proxy chain from sequence to predicted property to measured property and what accuracy is expected at each step, and the definition of success at the project level that the objective is intended to track.
That last component is the one most often skipped. Without a definition of project-level success, there is no way to know whether optimizing the fitness objective actually helped. A 40% improvement in Tm while retaining activity is a good round result only if thermostability was the bottleneck preventing project progress. If the actual bottleneck was expression yield and you did not include that in the fitness objective, three rounds of thermostability optimization leave you with a beautiful warm protein that still cannot be produced at useful quantities.
The fitness objective is where a protein engineering project succeeds or fails before any experimental work starts. Computational models are tools for navigating sequence space toward a specified objective. The better the specification, the more useful the navigation.